![]() ![]() There is a number of ways in which snapshots can be persisted. Such threshold will depend on a specific application and its characteristics, but in my experience creating a snapshot every few hundred of events worked well.įor example, if our threshold is set to 500 events, our latest snapshot was taken at version 2000, and we just wrote new events with sequence numbers 2499, 25, then it’s time to create a new snapshot. For that reason, the snapshots are typically created once a threshold of new events is reached. Usually, it doesn’t make sense to create a snapshot every time we write new events as the time it takes to write a snapshot would wipe out some of the gains we are hoping for. In a separate chaser process that monitors streams and creates a snapshot when a threshold is reached. Depending on how time-sensitive the command handling is, it can slow down the throughput of the consumer. If command handling is asynchronous (e.g reading commands from an MQ) the snapshot can be created as part of, or after command handling. This strategy will handle the creation of the snapshot in the background, so the client will not see increased latency. It’s one of the simplest strategies but might incur a latency penalty.Īfter writing new events and returning to the client. Right after new events are written to the store, and before returning to the client (if it’s synchronous). There are multiple ways in which snapshots can be implemented, and a specific strategy will depend on the needs. In practice, I’ve implemented snapshotting, because command handling became too slow as we had streams with a few thousand events or more. These factors include the size of events, database baking the event store, load on the database, network, number of large streams, latencies agreed with business and so on. I avoid recommending an arbitrary number of events (in a stream) after which you should start snapshotting, as it will depend on a number of factors. If we start noticing that the reads from the event store are taking too long, and it’s indeed correlated with the number of events, then it might be a good time to implement snapshots. If for example, we agreed with the stakeholders that 95% of commands will be handled with a latency of 200ms or less, then we can put appropriate metrics in place and measure how long it takes to read, write and return a result to the client. The state is updated with remaining events (if any)Īs we can see implementing snapshots in practice isn’t very complicated, but you might wonder - when is it a good time to start thinking about them? In order to make an informed decision, I recommend to have some data in place and make the decision based on that data. If the snapshot was found: the aggregate state is set from the snapshot, the aggregate version is set to the snapshot versionĪll remaining events are read from the event store starting from the current aggregate version ![]() Latest snapshot of an aggregate is read from a snapshot store Then before a command is handled we can load the latest snapshot and only new events since the snapshot was created.Ī generalised flow of using snapshots looks like follows: What we can do instead is to create a snapshot of the aggregate state and save it. ![]() If for example a stream contains thousands of events, and we need to read all of them every time, then the time the system takes to handle a command will be noticeable. Snapshotting is an optimisation that reduces time spent on reading event from an event store. ![]() 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? What is snapshotting For a well-designed aggregate, it’s usually not a problem as its lifecycle is bounded to a specific period and the number of events doesn’t grow indefinitely. 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. In an Event Sourced system, the current state of an aggregate is usually reconstituted from the full history of events. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |