Chapter II · Area 08 of 12
The Question for Our ShopWhat happens if the connection to the payment provider drops after sending a request?
Here you will find the basics for distributed states, networks and handling partial failures.
6 Building blocks
Starting hereAssumptions about distributionWhat can go wrong?
Payment P-731 gets no response; the outcome is unknown, the order stays open.
What arrives, and how often?
Order B-1042 may reach the invoice worker twice; its identifier reveals the repeat.
How do participants agree on a shared result?
Cart in two regions: wait during a partition or accept locally; three replicas, two acknowledgements each.
Known names – and where they are
Network assumptions (fallacies) and partial failures show what can go wrong. Delivery classifies message loss and retries. CAP weighs consistency against availability, quorum defines confirmation groups, consensus secures a binding order.
Here you clarify what applies if the connection to the payment provider drops after sending. From this you derive delivery guarantees, replica groups and agreement across several nodes. Each building block shows its theme at our shop.
This is what you learnYou can derive a specific error and operating case for a shop process from a network assumption.
In the shopThe shop application requests an external payment provider. The team looks at what delay, separation and variable response times mean for the flow.
Assumptions about distribution OpenThis is what you learnYou can detect a partial failure and continue the affected flow with an explicit intermediate state.
In the shopThe shop stores an order and calls up the payment provider. The connection breaks off after sending, while the order management continues.
Partial failures OpenThis is what you learnYou can treat multiple delivery as a normal message case and schedule idempotent processing.
In the shopThe shop publishes an order for invoicing. A worker stores invoice and order identifier before confirming broker delivery.
Delivery guarantees OpenThis is what you learnFor a network outage, you can specify which consistency and availability commitment a replicated service prioritizes.
In the shopThe shopping cart is replicated in two regions. While the regions are separate, the shop decides whether changes to the shopping cart positions are accepted locally or deferred until a common view.
CAP & PACELC OpenThis is what you learnYou can calculate reading and writing quors and explain what overlap their configuration allows.
In the shopA distributed shopping cart storage uses three replicas. The team uses two confirmations for reading and writing and sees how the groups overlap.
Quorum OpenThis is what you learnYou can distinguish the purpose of a consensus protocol from replication and quorum.
In the shopVariant: A separately operated inventory service uses multiple replicas to log changes to shared stocks in an orderly manner. The shop itself remains a modular monolith.
Consensus OpenThese areas are technically directly related to Distributed systems together.