Posts tagged “event-sourcing”
There is quite a lot of confusion in the community with regards to EventStoreDB and Kafka - especially when it comes to event sourcing. Developers not familiar with both products are having a hard time deciding which technology they should use, how do they compare and what are the trade-offs that they will have to make.
In this article, you will learn what the two solutions offer, how to use them effectively, and when to use one over the other. In order to do that, we first need to agree on the definition of event sourcing and requirements that the solution should meet.
Read more
Tags event-sourcing, event store, kafka, distributed systems
In an Event Sourced system, the current state of an aggregate is usually reconstituted from the full history of events. It means that before handling a command we need to do a full read of a single fine-grained stream and transport the events over the network. For a well-designed aggregate, it’s usually not a problem as it’s lifecycle is bounded to a specific time period and the number of events doesn’t grow indefinitely. But what if our design isn’t optimal, or we have some outliers that are requiring thousands of events to be transported every time we want to handle a command?
Read more
Tags event-sourcing, aggregates, snapshots, event store
One of the topics that came up a few times (and I noticed quite a number of searches for it) is how the Aggregates and Projections differ or relate to each other. The reason for this confusion is that some parts of the implementation logic are very similar - in particular, the current state of an Aggregate derived from the event log. In this blog post, we will explore the differences and look at some examples.
Read more
Tags event-sourcing, projections, aggregates
Projections are one of the core patterns used in Event Sourcing. What we understand by ES is persisting changes that are happening in the application as a sequence of events (also called an event stream). With this context in mind we can define a projection as an answer to a question: what is the current state derived from the event stream?
Read more
Tags event-sourcing, projections
During the event stream processing sometimes it is desired to perform side effects. The challenge we address in this post is how to perform a replay of an event stream and don't retrigger already performed side effects. It turns out there are a couple of alternatives that can help us solve this problem and the specific solution will depend on needs and the type of event store in use.
Read more
Tags event-sourcing, projections
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 more
Tags cqrs, event-sourcing, projections
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 more
Tags event-sourcing, projections, cqrs
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
Tags event-sourcing, cqrs, projections
