Why this matters
- Distributed transactions across inventory and payment need sagas, not a single
@Transactional. - CQRS separates read models from write models for catalog scale.
- Architect rounds expect compensating actions and idempotent saga steps.
Saga pattern
L1 · FresherSplit long transactions into steps with compensating actions — cancel payment if shipment fails.
Orchestration vs choreography
L2 · IntermediateOrchestrator coordinates steps; choreography uses events only — pick based on visibility needs.
CQRS basics
L3 · AdvancedSeparate write models from read-optimized views — event handlers update search indexes for BookStore catalog.
Eventual consistency
L4 · ExpertDocument user-visible delays in read models; use sync reads only where business demands strong consistency.
On failure, run compensating transactions in reverse order
Hook
Placing a BookStore order reserves inventory, charges payment, and schedules shipping — three services that can fail independently. Sagas coordinate long-running workflows; CQRS separates write models from optimised read views.
Choreography vs orchestration
Choreography: each service reacts to events (OrderPlaced → reserve stock → StockReserved → payment). Orchestration: a saga coordinator issues commands and tracks state. BookStore checkout often starts with orchestration for clearer failure handling.
The rest of this guide is part of Pro
Free covers every fresher guide in full. Pro unlocks Senior, Staff and Architect guides across every track.
Still to come · 6 sections
- Saga state in Spring
- CQRS read model
- BookStore in action
- Runnable BookStore lab
- Failure modes in production
- Consistency model
Test yourself
Answer these before moving on — recall is what makes it stick.