What strategies are commonly used to decide when to take a new snapshot of an event-sourced aggregate — for example triggering on event count versus elapsed time — and what trade-offs does each have?

## What the decision actually turns on The decision of when to take a snapshot is fundamentally about controlling the worst-case cost of loading an aggregate, and the two axes you can trigger on are how many events have accumulated since the last snapshot, and how much time has passed. Each has a different failure profile, and most serious implementations combine them rather than pick one exclusively. ## Triggering on event count Event-count-based triggering says: after every N events appended to a stream since the last snapshot (a common choice is somewhere between 50 and 1,000 depending on how expensive each event's apply logic is), write a new snapshot. The appeal is that it directly bounds the thing you actually care about — the number of events that must be replayed on the next load — regardless of how much wall-clock time those events took to arrive. - A **hot aggregate** that receives 10,000 events in an hour gets snapshotted roughly every few minutes. - A **cold aggregate** that receives one event a month might go a year between snapshots and simply never need one, because its full replay is cheap anyway. This adaptivity is the main strength: snapshot frequency naturally tracks write activity, so you spend snapshot I/O where it actually saves replay time, and you don't burn storage snapshotting aggregates that barely change. The weakness is operational: it requires either checking the event count on every append (a counter read-and-compare on the hot write path, which adds a small amount of latency and coupling) or an asynchronous consumer that tails the stream and counts, which introduces the standard 'this consumer fell behind' failure mode. ## Triggering on elapsed time Time-based triggering instead runs on a schedule independent of the event stream's activity — a nightly cron job that snapshots every aggregate touched that day, or a background worker that snapshots any aggregate whose snapshot is more than 24 hours old. The strength is operational simplicity: it's a well-understood batch job, easy to monitor, easy to reason about ('every aggregate has a snapshot no older than a day'), and it doesn't touch the write path or add load-time coupling. The weakness is that it doesn't track write volume at all: an aggregate that receives 50,000 events in the twelve hours right after the last nightly run will have a 50,000-event tail to replay on any load that happens before the next run — the worst-case replay cost is unbounded by any guarantee the scheduler gives you. It can also waste effort snapshotting aggregates that received zero new events since the last snapshot, redoing identical work for no benefit unless the job explicitly skips unchanged aggregates. ## The two triggers side by side | Trigger | Fires on | Main strength | Main weakness | |---|---|---|---| | **Event-count-based** | N events since the last snapshot | adaptivity — it directly bounds the number of events replayed on the next load, regardless of wall-clock time | operational — a counter read-and-compare on the hot write path, or the 'this consumer fell behind' failure mode | | **Time-based** | a schedule independent of the event stream's activity | operational simplicity — a well-understood batch job, easy to monitor and easy to reason about | worst-case replay cost unbounded under bursty write patterns; can also waste effort on aggregates that received zero new events | Because each trigger fails in the case the other one handles well, many real systems combine them with an OR condition: snapshot when N events have accumulated since the last snapshot, or when X time has passed, whichever comes first — this caps replay-tail length under bursty write patterns (the count trigger fires) while still guaranteeing a maximum snapshot age under low-write patterns (the time trigger fires as a backstop). A further refinement some systems use is **reactive/opportunistic snapshotting**: if a load operation ends up replaying an unusually long tail (say, past some threshold), the loading code writes a fresh snapshot right then, on the theory that if it was expensive for this reader it will likely be expensive for the next one too. This trades a slightly more expensive read for cheaper subsequent reads and is self-correcting even if the proactive trigger's tuning was wrong. ## What each direction costs The concrete cost on both sides is worth naming precisely. More frequent snapshotting means: - more storage consumed (snapshots for the same aggregate accumulate unless old ones are pruned); - more write I/O and potential lock contention if the snapshot write touches the same storage as the event append; - more surface area for the staleness/versioning bugs described elsewhere (more snapshot versions in flight means more chances for a race between concurrent readers/writers). Less frequent snapshotting means cheaper writes and storage but a growing tail that eventually degrades read latency and, at the extreme, can make an aggregate effectively unloadable in a reasonable time budget if nobody notices the metric. ## How it lands in practice A concrete real-world instance: Akka Persistence (a JVM actor persistence framework used for event-sourced actors) exposes a simple count-based policy out of the box — you configure 'snapshot every N persisted events' per persistent actor — and leaves time-based or opportunistic strategies to application code layered on top, which is exactly the pattern of picking a simple default (count) and composing additional triggers where the workload demands it. In practice, teams tune N empirically: start around a few hundred events, watch p99 aggregate-load latency, and adjust down for hot aggregates or up for cheap-to-replay ones.