Building Blocks


Command Query Responsibility Separation creates a separate conceptual model for querying the database from modifying the database. By separating these two responsibilities the CQRS architectural style allows us to optimize each model independent of the other. This can be particularly useful where the two conceptual models are not isomorphic, or it is desirable to easily separate the load of read and writes to the database. See CQRS 

Task Queues

A request to a web process should respond rapidly (<250ms) otherwise the web process will become blocked dealing with existing requests and unable to handle new ones. In a worst case scenario the web server has to queue requests, and eventually reject them. To avoid this issue a web server should choose to handle requests asynchronously. This can mean use of the reactor pattern (such as Node.js or even C#'s async-await pattern), but there can be performance and availability advantages for work that is asynchronous to the user (i.e. returns a 202 Accepted), or fire-and-forget, in handing the work off to a worker process via messaging middleware. This approach is called a Task Queue. See the white paper here (pdf)


Brighter can be used as a lightweight broker approach to communication between microservices. A microservice acting as a producer can either send a command to a queue, that a consumer microservice listens to, or publish an event, that zero or more consumers can react to. The advantage of using a message oriented middleware over RPC is that we remove temporal coupling - the consumer does not have to be running when the producer sends the messsage. The advantage of using an event over a command is that we remove behavioral coupling. The producer has no idea how or if consumers will process the event. See Smart End points And Dumb Pipes