Event Sourcing in 1 diagram and 205 words
Explained as simply as possible… but not simpler.
A pattern where the system state is rebuilt by replaying a chronologically-ordered log of immutable events instead of storing only the latest data snapshot.
Modern distributed systems need reliable audit trails and the ability to time-travel or rebuild state after bugs. By persisting every state-changing event, you avoid complex “update-in-place” logic and gain a permanent record. It pairs naturally with CQRS (separating writes and reads) and message streaming platforms.
Use Event Sourcing when you must guarantee a complete history of changes, enable easy rollback/replay, or drive real-time projections from an event log.
You need to know
Event immutability is non-negotiable – once stored, events are append-only; fixes come as compensating events, not edits.
Projections build current views – read models, caches, or materialized views are regenerated by replaying events; keep them disposable because they can always be rebuilt.
Versioning matters – as schemas evolve, you must version events and provide up-converters/down-converters to stay backward compatible.
Popular technologies
Apache Kafka / Redpanda – durable, ordered event log widely used as the source of truth.
KurrentDB – purpose-built database with native event-sourcing semantics (streams, idempotent appends).
Axon Framework (Java) – toolkit combining Event Sourcing, CQRS, and sagas for JVM ecosystems.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️
This is a cornerstone of any distributed system design.