Design a Food Order and Delivery Tracking System

Quick 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 Order and Delivery Tracking System

Company: Amazon

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Online Assessment

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.

Amazon logo
Amazon
Oct 15, 2026
mediumSoftware EngineerOnline AssessmentSystem Design
0
0

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 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?