Food delivery

The problem

Customers browse restaurants, build an order from a menu, pay and track delivery. Restaurants accept and prepare orders. Couriers pick up and deliver them.

Entities

100%

Figure SDA-LLD-09-1 · Food delivery classes · © forcsguy.com

OrderItem copies the name and price at purchase time. Later menu edits must not change old orders.

The order lifecycle

100%

Figure SDA-LLD-09-2 · Order status · © forcsguy.com

Each party may trigger only some transitions: the restaurant accepts and marks ready, the courier marks picked up and delivered, the customer may cancel early. Keep the allowed-transition table in one place.

const next: Record<string, Record<string, string>> = {
  PLACED:    { restaurantAccepts: "ACCEPTED", restaurantRejects: "CANCELLED", customerCancels: "CANCELLED" },
  ACCEPTED:  { startPreparing: "PREPARING" },
  PREPARING: { courierPicksUp: "PICKED_UP" },
  PICKED_UP: { courierDelivers: "DELIVERED" },
};
function apply(order: Order, event: string) {
  const to = next[order.status]?.[event];
  if (!to) throw new Error(`${event} not allowed in ${order.status}`);
  order.status = to; order.notifyAll();      // observers: customer, restaurant, courier apps
}

Assigning a courier

100%

Figure SDA-LLD-09-3 · Courier assignment · © forcsguy.com

Matching (nearest, fastest, fairest) is a strategy, as in the cab-booking lesson. Batching two orders for one courier is an extension with its own route check.

Design notes

• Price calculation (items, taxes, fees, discount) lives in one service used by cart, checkout and invoice.
• Menu availability: items can sell out; check at add-to-cart and again at placement.
• Idempotent placement: a double tap must not create two orders; use a client-generated order key.
• Notifications use the Observer pattern on status changes.
• Failures: payment fails (do not place), restaurant unresponsive (timeout and refund), courier cancels (reassign).

Real-world reading