Performance and Scaling — Event Sourcing & CQRS

Scaling concerns: stream length (snapshots or shorter streams), write contention on hot streams (smaller aggregates), projection throughput (batching, parallelism per stream/partition, efficient upserts), storage growth (archiving old events to cheap storage, compression), and read-model scaling (replicas, caches, search). Measure append latency, projection lag and rebuild time as first-class metrics.

Scaling issues

Concern	Symptom	Mitigation
Long streams	Slow aggregate loads	Snapshots; period streams
Hot streams	Concurrency conflicts, retries	Smaller aggregates; split by sub-entity
Projection lag	Stale reads	Batching, parallel partitions, faster upserts
Storage growth	Large tables, slow backups	Archive/tier old events, compression
Slow rebuilds	Hours/days to replay	Bulk loads, parallelism, snapshots of projections

Metrics to track
event_append_latency_seconds{store="postgres"}            p99
projection_lag_seconds{projection="order_summaries"}
aggregate_concurrency_conflicts_total{aggregate="Account"}
projection_rebuild_duration_seconds{projection="order_search"}

Common pitfalls

Ignoring rebuild time until you need one urgently.
Single-threaded projections for all events.
Unbounded event table growth.

Key points

Small streams and aggregates
Fast, parallel projections
Plan storage tiering and rebuild time

Further reading: Azure Architecture: Event Sourcing

Practice questions

What indicates a hot aggregate in an event-sourced system?

Answer

Frequent optimistic-concurrency conflicts and retries on the same stream, as many writers compete to append.

Why measure projection rebuild time?

Answer

Bug fixes and new read models depend on replays; if rebuilds take days, you can't recover or evolve quickly.