Order #4471 just hit your system at 14:02. The flow:
<ol>
<li>OrderService creates the order (Postgres) ✅</li>
<li>PaymentService charges $89.50 to Stripe ✅</li>
<li>InventoryService tries to reserve the SKU → fails (oversold by 3 units)</li>
<li>ShippingService never gets called</li>
</ol>
You’re now holding the customer’s money, no inventory to ship, and an order stuck in PENDING. In a monolith you’d wrap all 4 in a transaction and ROLLBACK. You can’t do that across 4 services with 4 databases.
What do you reach for?
A) Choreography Saga — each service publishes events, the next reacts, failures trigger compensating events backward through the chain.
B) Orchestration Saga — a central orchestrator (a state machine) calls each service in order and dispatches compensations on failure.
C) Two-Phase Commit (2PC) — coordinator locks all 4 services in PREPARE, then commits atomically (or aborts).
D) Outbox + eventual consistency — each service writes locally + an outbox row, a relay publishes events async, downstream services converge.
All four are real patterns shipping in production right now. Only one is the right call for a 4-step checkout where steps must run in order and each one needs a specific compensation.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
If your team has ever argued about choreography vs orchestration at 2am, share this with them. That argument is worth more than the post.
Drop your answer 👇
#30DaysOfSystemDesign #Day10 #SystemDesign #DistributedSystems

You can share you thought with this squad 

Backend Developer 

A practical system design scenario presents a 4-step checkout flow across microservices (OrderService, PaymentService, InventoryService, ShippingService) where a failure mid-flow leaves the system in an inconsistent state. Since a traditional database ROLLBACK is impossible across multiple services and databases, four distributed transaction patterns are compared: Choreography Saga, Orchestration Saga, Two-Phase Commit (2PC), and Outbox with eventual consistency. Readers are prompted to pick the best pattern for an ordered, compensatable checkout flow.

10/30 Days System Design Questions!

✅ Answer: B — Orchestration Saga
Why B wins:
4-step checkout with strict ordering + per-step compensations = exactly what an orchestrator is built for. Stand up a CheckoutSaga state machine (Temporal, AWS Step Functions, Camunda, or hand-rolled). It calls each service in order: OrderService → PaymentService → InventoryService → ShippingService. Each step has a registered compensation: CancelOrder, RefundPayment, ReleaseInventory. When Inventory fails, the orchestrator walks backward and refunds automatically. State is durable, observable, replayable. At 3am you open the orchestrator UI and see exactly which step failed with full inputs/outputs.
<img src="https://media.daily.dev/image/upload/s--QCBrSsMq--/f_auto/v1778863909/ugc/content_313a5199-35ba-4ae9-bdb1-89c26015f177?_a=BAMAMiWQ0" alt="ChatGPT Image May 15, 2026, 07_28_30 PM.png">

Why A is the trap (Choreography):
Elegant on paper. Falls apart at 4+ steps with branching compensations. The business logic for “what happens when inventory fails after payment succeeded” gets smeared across 3 services that all need to know each other’s failure modes. Nobody owns the flow. No single place to see “what is the state of order #4471?” At 3am you’re piecing it together from events across 4 Kafka topics. Choreography is right for loose, fire-and-forget side effects — not sequential checkouts with specific compensations.

Why C is wrong (2PC):
Stripe doesn’t speak 2PC. Neither does any shipping carrier API. Beyond that, 2PC holds locks during PREPARE — one slow service stalls everything. At checkout volumes, the lock contention alone takes you down. Textbook answer that dies on contact with reality.

Why D is wrong (Outbox):
Outbox is infrastructure, not a saga. It solves how to reliably publish events after a local DB commit. It doesn’t define step ordering, doesn’t define compensations, doesn’t answer what happens when Inventory fails. You’d still need a saga on top of it.

Also, it would mean a lot to me if you could support my content and stay in touch 🙏
<ul>
<li>YouTube: <a href="https://www.youtube.com/@system-design-lab" target="_blank" rel="noopener nofollow">https://www.youtube.com/@system-design-lab</a></li>
<li>LinkedIn: <a href="https://www.linkedin.com/in/joud-awad/" target="_blank" rel="noopener nofollow">https://www.linkedin.com/in/joud-awad/</a></li>
<li>Medium Blog: <a href="https://joudwawad.medium.com/" target="_blank" rel="noopener nofollow">https://joudwawad.medium.com/</a></li>
<li>Substack: <a href="https://joudawad.substack.com/" target="_blank" rel="noopener nofollow">https://joudawad.substack.com/</a></li>
</ul>