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

Joud Awad

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 workflow.

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--j6IhW8wy--/f_auto/v1778862632/ugc/content_8e10f17b-2cd3-40fe-b89e-809bc03ddf56?_a=BAMAMiWQ0" alt="ChatGPT Image May 15, 2026, 07_28_30 PM.png">

This checkout flow across multiple microservices is a very practical and important system design scenario. It brings up so many real challenges like saga pattern vs 2PC, idempotency in payments, eventual consistency, and reliable event publishing.
For me the most critical part in such flows is always failure handling and recovery rather than just the happy path.

How important is learning System Design for someone who primarily works on the frontend side?
I understand basic concepts, but I often wonder should frontend engineers go deep into distributed systems, sagas, eventual consistency, etc., or is having surface-level knowledge usually enough?

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>