CQRS and Event Sourcing

Command Query Responsibility Segregation means writes and reads are served by different models. Commands (EnrollInCourse) check business rules and change state. Queries (GetMyDashboard) read from denormalized tables shaped for the screen.

Most products see 10 to 100 times more reads than writes. A separate read model can live in Redis, Elasticsearch or a dedicated replica and scale independently of writes.

Instead of a balance = 120 row, you store a journal: Deposited 100, Deposited 50, Withdrew 30. Current state is computed by replaying events. The journal is append only, nothing is overwritten.

Banks and accounting worked this way long before programming. You get a full audit trail, can rebuild state as of any date, and can build a new read model by replaying old events through a new projector.

To avoid replaying millions of events per request, you take snapshots: store the aggregate state every N events and replay only the tail.

The read model updates asynchronously, so right after a write the user may see stale data. That has to be designed into the UX, not hidden.

Events cannot simply be «fixed» in the database: mistakes are corrected with compensating events, and schema changes need upcasting of old events. For plain CRUD (profile, settings) this is needless complexity.

It fits domains where history has value: money, bookings, inventory, exchanges. LMAX, a trading platform, processed about 6 million orders per second on a single thread by keeping state in memory and rebuilding it from an event journal.