Event Sourcing in Production: Snapshots & Projections (2026)

Q: When should I use event sourcing instead of a normal database with CDC?

Use event sourcing when the *event* itself is the business artefact — a payment, a claim, a contract amendment, a position adjustment — and the *current state* is a derived convenience. Use a normal table with [Debezium CDC into a warehouse](/en/blog/microservices-pattern-database-per-service-cross-service-joins-cdc-debezium-2026) when the *current state* is the business artefact (a customer profile, a product catalogue entry, a feature flag) and the audit log is a side concern. The decision is per-aggregate, not per-system: a single service can run an event-sourced `Order` aggregate alongside a normal-table `Customer` aggregate, joined at the projection layer. The classic mistake is event-sourcing the whole domain because the conference said so; eighteen months later you have hundreds of event types, no projection-rebuild SLA, and a first-time schema change that takes a quarter to ship. Event sourcing rewards aggregate-by-aggregate discipline; blanket adoption punishes it. The break-even rule: event-source if you need temporal queries, bi-temporal modelling, regulatory audit as a primary requirement, or business logic that genuinely reacts to *what changed*; otherwise prefer the simpler architecture.

Q: What is the right size for an event-sourced aggregate?

An aggregate is the consistency boundary — the smallest cluster of state that must change atomically for a business invariant to hold. Greg Young’s original CQRS Documents and Eric Evans’s Domain-Driven Design converge on the same heuristic: if you can describe the invariant in a sentence, the aggregate is correctly sized; if you need three sentences and a diagram, it is too coarse. Two failure modes dominate. Too coarse (modelling `Customer` to own orders, addresses, payment methods, and preferences) creates stream hotspots, contended optimistic-concurrency, unbounded snapshots, and minute-long projection rebuilds for one customer. Too fine (modelling each line item on an order as its own aggregate) means placing an order is now a saga across N aggregates with no atomicity, and the simplest invariant ("order total equals sum of lines") cannot be enforced because the lines live in separate streams. The fix in both directions: the aggregate encompasses exactly the state required for one transactional invariant. Cross-aggregate workflows are [sagas](/en/blog/microservices-pattern-saga-orchestration-2026), never transactions disguised as single events.

Q: Should I use EventStoreDB, Marten, or Kafka as my event store?

Three production families dominate in 2026 and the choice depends on volume, audit retention, and whether the team operates a streaming platform. EventStoreDB (now KurrentDB after the 2025 rebrand) is the canonical purpose-built choice with per-stream optimistic concurrency, native JavaScript projections, and persistent subscriptions — right for 5–500M events/month with strict audit. Marten layers an event-sourcing API over Postgres (`mt_events`, `mt_streams`, projection tables) and is the natural pick for teams who already operate Postgres and want to avoid a new platform — cost roughly $500–2,000/month at moderate scale versus $4,000–12,000/month for managed Kafka + Debezium. Kafka can be an event store but only with asterisks: KIP-98 transactions and EOS make it viable, but Kafka by itself does not give per-stream optimistic concurrency — you reconcile that in the application via [the transactional outbox pattern](/en/blog/microservices-pattern-outbox-pattern-2026). Most teams use Kafka as the transport between an event-sourced aggregate and downstream projections, with EventStoreDB / Marten / Postgres-with-outbox as the actual store of record. The decision matrix is volume-driven: under 5M events/month go Postgres + outbox; 5–500M go EventStoreDB or Marten; above 500M and the team operates streaming, Kafka + transactional outbox + Postgres reference becomes attractive.

Q: What is a snapshot and what is the right cadence?

A snapshot is a periodic cache of the aggregate’s left-fold of its events, used to short-circuit aggregate load: read the latest snapshot, then replay only events with version greater than the snapshot’s version. **Snapshots are a load-time optimisation; they are never the source of truth — the events are.** Two failure modes follow from misunderstanding this. First, business logic that reads from a snapshot without replaying the tail loses the most recent commands. Second, treating the snapshot as authoritative means the log stops being the system of record, and the architecture has lost its core invariant. The right cadence is empirical, not theoretical, and it is a function of average event size, aggregate event-rate, and load-latency budget. For an aggregate with 10 events/day and a 50ms load budget, snapshot every 100 events. For a hot ledger account with 1,000 events/hour and a 20ms budget, snapshot every 50. For long-lived aggregates exceeding ~10,000 lifetime events, a snapshot strategy is not optional. Three patterns survive: versioned snapshots (throw away on schema change, replay from event 0), upcasters (pure functions migrating snapshot shape at load time), and disposable snapshots (delete on every deploy — only works for small aggregates). The cadence is the trade-off between snapshot-table growth and load latency; instrument it, do not guess.

Q: How do I rebuild a projection in production without downtime?

By running the new projection consumer side-by-side with the old, waiting for it to catch up, atomically flipping read traffic via a feature flag, and decommissioning the old projection. This is the projection-side equivalent of [the strangler fig migration pattern](/en/blog/microservices-pattern-strangler-fig-migration-2026). The acceptable rebuild window is a function of projection size: under 1M events, single-threaded replay in hours is fine; 1M–100M events demands parallel-by-stream replay with 4–16 workers and batched writes within a single shift; 100M–10B events requires sharding by aggregate-ID hash, idempotent batch writes, and watermark checkpointing across 1–3 days; above 10B events, only the continuous side-by-side pattern works — there is no incident-response window large enough to wait for a synchronous rebuild. Idempotency is non-negotiable: every projection write must be keyed by event position or a deterministic hash of `aggregate_id + version`, with `INSERT ... ON CONFLICT DO UPDATE` semantics, never raw `INSERT`. The single most common production mistake is to deploy event sourcing without ever measuring rebuild time — then a schema change forces a rebuild and the team discovers the projection takes nine days. The deeper treatment of idempotency is in [the idempotency in distributed systems pattern](/en/blog/microservices-pattern-idempotency-distributed-systems-2026); the rule worth surfacing here is that a projection-rebuild SLA is a real production metric, not a documentation aspiration.

Q: How do I handle a breaking schema change to an event type?

Three patterns survive in production. (1) **Upcasters at the read boundary.** A pure function migrates an old event into the current shape at the point of reading from the store — the old event remains untouched in the immutable log, the upcaster runs every load, application code only sees the current version. Robust but compositional: chains accumulate over a decade and demand periodic upcaster-collapse via log rewrites or floor-version bumps. Axon Framework’s upcaster chain is the canonical reference. (2) **Weak schemas with BACKWARD compatibility.** Use Avro or JSON Schema with strict BACKWARD enforcement at the registry boundary: every new schema version must be readable by old consumers, every old version readable by new. Adding optional fields is safe; renaming a field is a three-release dance (add new + populate both + remove old); removing a required field is never safe. The pairing with [the schema registry contract testing pattern](/en/blog/microservices-pattern-schema-registry-contract-testing-avro-protobuf-jsonschema-2026) is mandatory. (3) **New event types for semantic changes.** `OrderPlaced.v1` and `OrderPlacedWithLineDiscount.v1` are separate types, never merged — the temptation to bump `OrderPlaced.v2` should be resisted because in practice "v2" is a different event with overlapping fields and consumers get silent semantic drift. The combined discipline: weak schemas for additive changes, new types for semantic changes, upcasters only when an old event’s data is no longer expressible. Never edit the log; never rename event types; never delete event types in a system with consumers.

Q: How does event sourcing compose with CQRS, sagas, and the outbox pattern?

Event sourcing and CQRS are paired by design — Greg Young coined them together in 2010 — and every read model is a projection optimised for one query shape. The [cache-aside CQRS pattern](/en/blog/microservices-pattern-cache-aside-cqrs-2026) is the natural front-end caching layer over those projections, with explicit staleness semantics so the read API never blocks on projection consistency. [Saga orchestration](/en/blog/microservices-pattern-saga-orchestration-2026) handles cross-aggregate workflows: an order that touches inventory, payment, and shipment is a saga over four event-sourced aggregates, each with its own stream and its own optimistic-concurrency, glued by a state machine that listens to the events and dispatches the next command. [The outbox pattern](/en/blog/microservices-pattern-outbox-pattern-2026) is how an event-sourced aggregate publishes to downstream consumers without the dual-write problem: events go to the event store and to the outbox in the same transaction, and Debezium streams the outbox to Kafka. The broader landscape of distributed-consistency patterns is in [2PC alternatives](/en/blog/microservices-pattern-two-phase-commit-alternatives-saga-tcc-outbox-reservation-2026) and [event-driven architecture](/en/blog/microservices-pattern-event-driven-architecture-2026). Event sourcing is one tool in this set, not the answer to every consistency question.

Q: Can I edit or delete an event in the log if I made a mistake?

No. The fastest way to destroy event sourcing is to "fix" a bad event by editing it in the database. **The log is immutable; corrections are new events.** This is non-negotiable, and it is the discipline that distinguishes event sourcing from a misnamed audit log. If a payment was recorded incorrectly, the correction is a new `PaymentCorrected` event referencing the original; if an order should have a different total, a `OrderTotalAdjusted` event is appended. Bi-temporal modelling makes this natural: events have an `occurred_at` (when the business event happened) and a `recorded_at` (when the system captured it), and corrections to past events are themselves new events with new `recorded_at` timestamps. The audit story depends entirely on log immutability — once the log can be edited, every downstream consumer’s history becomes untrustworthy, and the regulator has no chain of custody. The only exceptions are GDPR / DPDPA right-to-erasure cases where personal data must be physically removed; the production pattern is to encrypt PII fields with per-subject keys and "delete" by destroying the key (cryptographic erasure), preserving the event’s structural integrity while making its sensitive payload unreadable. This composes cleanly with [the PII redaction pipeline pattern](/en/blog/pii-redaction-pipeline-llm-presidio-ner-reversible-tokenisation-2026) for ingest-time protection.

Q: What does the cost model look like at production volume?

A worked example at 50,000 events/day across 1,000 active aggregates with 10M lifetime events per aggregate and 500-byte average event size — a typical financial-ledger workload — looks like this. On Postgres + outbox: roughly $500–2,000/month for managed Postgres at the OLTP write rate, plus $200–500/month for an outbox-to-Kafka shipper. On EventStoreDB / KurrentDB Cloud: roughly $1,500–4,000/month for a three-node cluster sized for the workload with native projections. On Kafka + transactional outbox + Postgres reference: $4,000–12,000/month for managed Kafka with EOS plus the Postgres bill. The snapshot strategy materially affects load latency: with no snapshots, every load replays 10M events at 500 bytes = 5 GB read — untenable; snapshot every 1,000 events gives 10,000 snapshots per aggregate at ~50KB each = 500MB snapshot table per aggregate, with loads reading one snapshot plus up to 1,000 events ≈ 550KB — single-digit-ms loads. Snapshot every 10,000 events shrinks the snapshot table tenfold but pushes loads to 50–80ms — borderline for interactive workloads. The architectural rule is that snapshot cadence is not optional for any aggregate exceeding ~10,000 lifetime events; instrument the load latency and tune empirically.

Q: What is the five-stage maturity ladder for event sourcing in production?

Stage 0 is the audit-log mistake — a team adds an `audit_log` table to a normal-state service and calls it event sourcing. There are no aggregates, no projections, no concurrency control, no schema discipline; the "events" are write-only and unread; the system of record is still the mutable state. Cost of correction is medium because the architecture is unchanged. Stage 1 is one aggregate event-sourced — a high-value aggregate (typically a ledger or a position) on Postgres + outbox, two or three projections, an emerging schema discipline, a snapshot strategy in place. Most teams stop here for two years and that is fine; they get the audit story for the aggregate that needs it without paying for the rest. Stage 2 is multiple aggregates on a shared platform — five to twenty event-sourced aggregates across two or three services, sharing EventStoreDB or a Postgres event-store schema, with projection-rebuild tooling, a versioned-event-type registry, and a documented schema-evolution workflow; the projection-rebuild SLA exists and is rehearsed. Stage 3 is continuous side-by-side projections — the team has projections that take longer to rebuild than the incident-response window, and has built side-by-side rebuild tooling so schema evolution is a weekly deployment, not a quarterly migration. Stage 4 is bi-temporal aggregates with cross-team upcaster discipline — the system supports bi-temporal queries, the upcaster directory is reviewed quarterly with a periodic upcaster-collapse process, every event type has an owner, every projection has an SLO, new aggregates take days not quarters. This is where regulated finance and healthcare operate.