Snapshots in Event Sourcing

Enabling snapshotting for an aggregate is entirely configuration — nothing about the aggregate's own event-sourcing handlers needs to change. You tell Axon how often to take a snapshot, and it handles the rest automatically.

@Aggregate(snapshotTriggerDefinition = "accountSnapshotTrigger") points AccountAggregate at a named SnapshotTriggerDefinition bean. EventCountSnapshotTriggerDefinition is the simplest trigger strategy: take a new snapshot every N events applied by this aggregate — 50, in this example. Axon takes care of serializing the aggregate's current state into a snapshot and storing it once that threshold is crossed; none of that logic needs to be written by hand.

Other trigger strategies exist for different needs — for example, triggering based on elapsed time rather than event count — but event-count triggering is the most common starting point, since it directly targets the actual cost driver: how many events would otherwise need replaying.

@Aggregate(snapshotTriggerDefinition = "accountSnapshotTrigger")
public class AccountAggregate {
    // Nothing about the aggregate's own code needs to change at all.
}

@Configuration
public class SnapshotConfig {

    @Bean
    public SnapshotTriggerDefinition accountSnapshotTrigger(Snapshotter snapshotter) {
        return new EventCountSnapshotTriggerDefinition(snapshotter, 50); // Snapshot every 50 events.
    }
}

Once a snapshot exists, loading an aggregate changes shape. Instead of "replay every event from the first one," it becomes "load the most recent snapshot, then replay only the events that happened after it."

Picture an account with 53 total events, snapshotted at event #50. Loading this aggregate now means: load the snapshot taken at event #50 directly (skipping the replay of events #1 through #50 entirely), then replay only events #51, #52, and #53 on top of it. Three events get replayed instead of fifty-three — and that gap only widens as more events accumulate between snapshots.

This is worth internalizing because it removes any anxiety about snapshotting being risky: a snapshot is never the only copy of anything. It's a cache of a calculation, not a second source of truth. If a snapshot ever gets corrupted or goes stale in a way that matters, deleting it and letting Axon rebuild it from full history is always a safe, correct fallback.

This kind of optimization matters most for aggregates that stay in heavy, long-term use — a long-lived, actively transacted bank account being the clearest real-world example — where the gap between "replay everything" and "replay since the last snapshot" only keeps growing over the aggregate's lifetime.

Reserve snapshotting for aggregates that genuinely accumulate a large number of events over a long lifetime — a long-lived bank account being the canonical example — rather than enabling it universally, by default, for every aggregate type in a system. A reasonable approach is to leave snapshotting off until profiling or production load actually shows aggregate loading time becoming a measurable bottleneck for a specific aggregate type, then configure a trigger threshold sized to that aggregate's real event volume.

A second pitfall: forgetting that a change to an aggregate's internal fields (adding, renaming, or removing state) can make old snapshots incompatible with the current aggregate code. If a snapshot fails to deserialize correctly after a change like this, the safe response is to delete the stale snapshots and let Axon rebuild fresh ones from full event history — never to try to hand-patch a serialized snapshot to match new code.