Design food-delivery tracking that exposes order status, courier location, customer notifications, and restaurant order details. Separate durable state from frequent location updates and explain duplicate delivery, stale data, and reconnection behavior.
Design a food-delivery tracking system with four requirements:
1. After placing an order, the customer can see its status.
2. The customer can track the delivery partner's location.
3. The customer receives notifications when the order status changes.
4. The restaurant receives the order details.
### Constraints & Assumptions
- Focus on tracking after order placement; payment, menu browsing, and courier assignment are not specified requirements.
- Clarify the order states, location freshness, and notification channels.
- Treat scale estimates and delivery guarantees as design assumptions.
### Clarifying Questions to Ask
- Which actors may advance each order state, and can updates arrive out of order?
- How often should the location refresh, and how should stale location be displayed?
- Does the restaurant need to acknowledge receipt of the order details?
### Part 1 — Order State and Restaurant Delivery
Describe the authoritative order record and the path that delivers details to the restaurant. Explain retries and status updates.
#### What This Part Should Cover
- Order identity, permitted transitions, and authorized writers.
- Durable delivery intent and restaurant acknowledgement.
- Duplicate and out-of-order update handling.
### Part 2 — Location and Customer Notifications
Describe location ingestion, customer subscription, and status notifications, including intermittent client connectivity.
#### What This Part Should Cover
- Location timestamps and access restricted to the relevant delivery.
- A current-state read path plus incremental updates.
- Notification deduplication and reconnection behavior.
```hint
Order state changes and location samples have different durability and update-frequency needs.
```
### What a Strong Answer Covers
The design should trace each of the four requirements to a concrete read or event path, preserve a reliable order history, and present stale or missing location honestly. Notifications should inform users without becoming the only source of order truth.
### Follow-up Questions
- What happens if the restaurant receives an order twice?
- How does a reconnecting customer recover missed status changes?
- When should the delivery partner's location stop being visible to the customer?
Overview: Design food-delivery tracking that exposes order status, courier location, customer notifications, and restaurant order details. Separate durable state from frequent location updates and explain duplicate delivery, stale data, and reconnection behavior.
Design a food-delivery tracking system with four requirements:
After placing an order, the customer can see its status.
The customer can track the delivery partner's location.
The customer receives notifications when the order status changes.
The restaurant receives the order details.
Constraints & Assumptions
Focus on tracking after order placement; payment, menu browsing, and courier assignment are not specified requirements.
Clarify the order states, location freshness, and notification channels.
Treat scale estimates and delivery guarantees as design assumptions.
Clarifying Questions to Ask Guidance
Which actors may advance each order state, and can updates arrive out of order?
How often should the location refresh, and how should stale location be displayed?
Does the restaurant need to acknowledge receipt of the order details?
Part 1 — Order State and Restaurant Delivery
Describe the authoritative order record and the path that delivers details to the restaurant. Explain retries and status updates.
What This Part Should Cover Guidance
Order identity, permitted transitions, and authorized writers.
Durable delivery intent and restaurant acknowledgement.
Duplicate and out-of-order update handling.
Part 2 — Location and Customer Notifications
Describe location ingestion, customer subscription, and status notifications, including intermittent client connectivity.
What This Part Should Cover Guidance
Location timestamps and access restricted to the relevant delivery.
A current-state read path plus incremental updates.
Notification deduplication and reconnection behavior.
What a Strong Answer Covers Guidance
The design should trace each of the four requirements to a concrete read or event path, preserve a reliable order history, and present stale or missing location honestly. Notifications should inform users without becoming the only source of order truth.
Follow-up Questions Guidance
What happens if the restaurant receives an order twice?
How does a reconnecting customer recover missed status changes?
When should the delivery partner's location stop being visible to the customer?