Event Sourcing & CQRS

A traditional DB stores the current state: user 42 has balance $150. How they got there is gone. Event sourcing inverts this: you store the stream of changes (deposits, withdrawals, transfers), and "current balance" is a derived projection. It's how banks actually work — a ledger of transactions, not a balance field.

CQRS (Command Query Responsibility Segregation) splits the system into a write side (commands that produce events) and one or more read sides (projections optimized for each query shape). Pair the two and you get auditability, temporal queries, independent scaling of reads and writes.

Useful in: financial systems, order management, collaborative editing, anywhere "how did we get here?" matters.

1. Commands. User intents — "transfer $50 from A to B." Validated against current state. If valid, emit events.
2. Events. Facts of what happened — "$50 withdrawn from A (event id e7, timestamp t)" and "$50 deposited to B (e8, t)". Immutable. Appended to the event log (Kafka, EventStore, Postgres table).
3. Projections. Read-side views computed by replaying events. Current-balances view. Transactions-by-day view. Suspicious-activity view. Each tuned for its query pattern.

# Order saga: reserve → charge → ship → notify
# On failure, compensate completed steps in reverse order.

class Saga:
    def __init__(self, steps):
        self.steps = steps  # [(action, compensation), ...]
        self.completed = []

    def run(self, ctx):
        for action, compensate in self.steps:
            try:
                action(ctx)
                self.completed.append(compensate)
            except Exception as e:
                # Roll back completed steps in reverse
                for c in reversed(self.completed):
                    try: c(ctx)
                    except: pass  # compensations themselves must be idempotent
                raise

# Use Saga when: transactions span services, low contention, some slack OK
# Don't use Saga when: strict ACID required, low value (just pay the cost of 2PC)

Gains:

• Free audit trail — every change traceable to a specific event with actor and timestamp.
• Time travel — replay events up to any past instant to reproduce historical state (great for debugging, regulatory reports).
• New projections cost nothing — add a view later, replay events to build it. No data migration.
• Read and write scale independently — beefy event-log cluster, many lightweight projection services.
• Natural fit for pub/sub — events flow downstream to analytics, notifications, search indexing.

Costs:

• Every query goes through a projection. Eventual consistency — just wrote an event? The balance view may lag 50ms.
• Event schema evolution is a nightmare. You rename a field; old events in the log still have the old name. Versioning + upcasters forever.
• Storage grows linearly with activity, not with current state. Compaction strategies needed (snapshots).
• Conceptual weight — the team has to think in events, not tables. New hires hate it for 6 months.

A user has 10,000 events over 5 years. Every time you query their balance, replaying 10k events takes seconds. Solution: snapshots.

Periodically (every 100 events, or daily), compute the current state and persist it with the event ID up to which it's been applied. When querying: load the latest snapshot, apply events after that snapshot's event ID. Balance computation goes from "replay 10,000" to "replay 20." Latency becomes constant.

Snapshots are derived data — you can always rebuild from events, so their storage is optional and they can be regenerated after a bug fix. This keeps the event log as the single source of truth while making queries practical.

Stock exchange is naturally event-sourced (every order is an event). Payment gateway uses event sourcing for the ledger. E-commerce order state is increasingly event-sourced for refund/return workflows.