CQRS allows you to create read models specifically optimized for product display (denormalized, cached) while keeping the write model focused on purchase transactions with proper validation.

Event Sourcing stores all state changes as events. To get historical state, replay events for that aggregate up to the desired timestamp. This is 'time travel' - a key benefit of event sourcing.

Events are immutable, but projections are derived. Fix your projection code, drop the read model, and rebuild it by replaying events. The projection will now calculate totals correctly for all historical data.

Sagas use compensating transactions. When Payment fails, the saga runs compensations for completed steps in reverse order. 'Reserve Room' gets compensated by 'Release Room' to return to a consistent state.

Snapshots capture state at a point in time. Instead of replaying 10M events, load the latest snapshot and replay only events since then. This can reduce load time from 30 seconds to milliseconds.

Events are immutable - never modify them. Upcasters transform old event formats to new ones at read time. Old events stay unchanged, but your application always sees the current format.

In choreography, services communicate through events. Service B subscribes to relevant failure events (e.g., PaymentFailed) and runs its compensation when it receives one. There's no central coordinator.

Projections should track their position in the event stream (checkpoint). On crash, resume from the last checkpoint and reprocess events from there. No data loss, minimal reprocessing.

Optimistic concurrency means writes include an expected version. The first write succeeds and increments the version. The second write finds the wrong version and fails. It must reload, re-apply logic, and retry.

Event sourcing provides a complete audit trail. When a customer disputes a charge, Netflix can replay the exact sequence of events (subscription changes, payments, credits) to show precisely what happened and why.

Handle eventual consistency gracefully. Options: return data in the command response, use optimistic UI (show the order before projection updates), or implement read-your-writes consistency. Don't make the user wait or refresh.

Orchestration provides centralized control, making complex workflows easier to understand, monitor, and modify. Choose choreography for simpler flows where loose coupling is more important than visibility.

Each projection maintains its own subscription to the event stream. They process independently and in parallel. One event can feed many projections - that's the power of event sourcing.

Compensations are critical for consistency. If a compensation fails, retry with exponential backoff. If it keeps failing, alert operations for manual intervention. Never skip compensations or you'll have inconsistent data.

CQRS (separating reads/writes) and Event Sourcing (storing events as truth) are separate patterns that work well together but can be used independently. CQRS without ES uses separate read/write DBs. ES without CQRS uses events but queries the same model.