To achieve rapid delivery, quick-commerce companies such as Zomato rely on strategically located dark stores stocked with commonly ordered items. Orders are accepted only if the item is available in a nearby dark store. Zomato bulk-purchases commonly ordered food items and stores them in these dark locations, ensuring they are ready for quick delivery. Once an order is placed, the food is warmed and delivered quickly.
Business Requirements
In order to accept an order, Zomato needs two things:
- Available food from the dark store.
- A delivery partner ready to deliver.
If either of these services fails, the order must be canceled.
Atomicity in DBMS (Database Management System)
From a database perspective, ensuring atomicity means that both the food preparation and the delivery assignment must happen as one atomic transaction — meaning either both succeed, or neither does.
- If the food is prepared but the delivery partner fails to show up, the food may spoil or need to be rewarmed.
- If the delivery partner is ready but the food is unavailable, the delivery partner will waste time, leading to poor user experience.
Two-Phase Commit (2PC) Protocol
To handle this, both the food preparation and delivery service must be completed atomically, and this is where the Two-Phase Commit (2PC) protocol comes into play. The 2PC protocol ensures that both services either succeed or fail together.
The Two-Phase Commit Protocol consists of two steps:
- Prepare Phase
- Commit Phase
How It Works:
When an order is placed, Zomato reserves both the food packets and a delivery agent before confirming the order. This ensures that orders are only accepted when both the food and delivery partner are reserved.
Prepare Phase:
- Both the food and delivery agent are reserved for a limited time (using a timeout to avoid deadlock).
- If both reservations succeed, the system moves to the commit phase.
- If either the reservation of food or the delivery agent fails, the transaction is canceled.
- If one succeeds but the other fails, the reservation is canceled and resources are released.
Commit Phase:
- If both the food and the delivery agent are successfully reserved, the order is committed.
- If either reservation fails, the order is canceled, and any held resources (food and delivery agent) are released.
Advantages:
- Guaranteed Atomicity: Ensures that either both the food and delivery are successfully reserved, or neither is.
- Guaranteed Isolation: Each transaction operates independently and doesn't interfere with other transactions.
Disadvantages:
- Slower Processing: Due to the steps required to ensure atomicity, the process may be slower than simpler approaches.
- Potential for Deadlocks: With multiple transactions attempting to reserve resources, deadlocks can occur unless managed carefully using timeouts and other safeguards.
Stay tuned for the code implementation blog!
Thanks for reading.
Top comments (1)
According to this design, the 2PC protocol is initiated after the user’s payment (ie, after placing the order). But if the food or a delivery partner isn’t available, I suppose a refund is in order. My question is: Why not check the availability of both resources first, and then take the payment. It could easily be implemented in the frontend; on the user’s cart screen, instead of taking the payment directly, have a checkout button in its place. After pressing it, the 2PC protocol is initiated. If both atomic operations succeed, the frontend displays the usual list of payment options, or directly redirects to the API of the user’s preference (eg Google Pay or SBI Collect OTP page). This way redundant refunds are avoided, I think.