When designing the architecture of a distributed / microservice system, one of the patterns used often is to make components communicate over an asynchronous message queue / bus / streaming platform. This approach has a lot of benefits, such as reduced coupling, improved resiliency and fault tolerance. It also creates some challenges, and one of them is finding an answer to a question: "Who defines and owns the protocol that services use to exchange messages?".
Read moreEvent Sourcing Projections patterns: Side effect handling
Running a projection doesn't have to mean that all we can do is to update read models used by APIs. It is possible to handle more complex use cases that involve triggering side effects on other systems, and still keep the code concise and resilient.
Read moreEvent Sourcing Projections patterns: Consumer scaling
Event Sourced systems implemented in tandem with Command Query Responsibility Segregation can handle very high volume of events and still deliver great experience for the users.
Because the Write Stack (command handling) is clearly separated from the Read Stack (query handling) we can prioritise which read models get updated first and which can be updated a bit later in case of a spike in traffic.
Read moreEvent Sourcing Projections patterns: Deduplication strategies
In a typical CQRS/ES system events delivered to projections have At-least-once delivery guarantee and because of that it is usually necessary to implement deduplication in order to achieve idempotency.
Although some of the message queue / streaming platforms claim that they can deliver exactly one semantics the answer to the deduplication problem problem is nuanced and we can’t get away without solving it.
Read more