🍔 Design Food Delivery (Swiggy) — System Design Interview Guide

Hard · Real-Time & Logistics

Design a food delivery platform like Swiggy or DoorDash where users browse restaurants, place orders, and track delivery in real-time, while managing restaurant menus, availability, and dynamic delivery pricing.

Open the interactive Food Delivery (Swiggy) design on PrepGrind → Drag load balancers, caches, databases, and queues onto a canvas, run a live traffic simulation to watch latency and bottlenecks under load, and follow the full interview walkthrough below — free, in your browser.

Functional requirements

• Browse restaurants filtered by location, cuisine, rating
• View menu, add items to cart, place order
• Real-time order tracking with delivery partner location
• Multiple payment methods: UPI, card, COD
• Restaurant portal: manage menu, mark availability, view orders
• Rating and review system for restaurants and delivery partners

Non-functional requirements & scale

• 50M orders per day during peak; 5M concurrent users
• Order placement to acknowledgment < 2 seconds
• Delivery ETA accuracy ± 2 minutes
• Restaurant discovery within 3km radius < 100ms
• No order loss — exactly-once order creation
• Live tracking update lag < 5 seconds

Capacity estimation

Similar to Ride-Sharing but more complex: multiple parties (user, restaurant, delivery partner). Order state machine: PLACED → CONFIRMED → PREPARING → OUT_FOR_DELIVERY → DELIVERED. Each party needs real-time updates. Restaurant availability is dynamic (can mark closed anytime).

Core entities

• Order — orderId, userId, restaurantId, partnerId, items[], status, totalAmount, deliveryAddress, createdAt
• Restaurant — restaurantId, name, location, cuisines[], rating, isOpen, prepTime, menuId
• MenuItem — itemId, restaurantId, name, price, category, isAvailable, imageUrl
• DeliveryPartner — partnerId, location (lat/lng), isAvailable, currentOrderId, rating

API design

• GET /api/v1/restaurants?lat=&lng=&radius=3km — Nearby restaurants. Returns sorted by rating/ETA.
• POST /api/v1/orders — Place order. Idempotency key in header. Returns { orderId, estimatedDelivery }.
• WS wss://app/orders/:orderId/track — Real-time order and delivery partner location updates.
• PUT /api/v1/orders/:orderId/status — Restaurant/partner updates order status.

High-level design

Order placed → Restaurant notified → Restaurant confirms → Matching assigns nearest available partner → Partner picks up → Live tracking via WebSocket. All state changes via Kafka; WebSocket pushes to users.

Deep dives

🗺️ Dynamic ETA Calculation

ETA = restaurant prep time + delivery time. Delivery time: distance / avg_speed + traffic factor. Use Google Maps Distance Matrix API or internal routing with live traffic. Cache ETA per restaurant-to-zone pair (update every 5 min). Delivery partner assignment: minimize max(ETA). Re-estimate ETA every 2 min during delivery based on actual partner location vs planned route.

🔄 Order State Machine

PLACED → CONFIRMED (restaurant accepts) → PREPARING → READY → PARTNER_ASSIGNED → PICKED_UP → OUT_FOR_DELIVERY → DELIVERED or CANCELLED. Each transition is a Kafka event. Timeouts: restaurant must confirm within 2 min else auto-cancel + notify user. Partner must pick up within 5 min of assignment else reassign. Store state in DB with version lock.

🍕 Restaurant Availability

Restaurant marks open/close at any time. On close: all active orders complete, no new orders. Mark in Redis (TTL-based) for fast lookup. Search API filters by isOpen. Problem: menu item goes out of stock mid-order. Solution: restaurant portal sends item-unavailable event → Kafka → Order Service checks items on order placement. Optimistic: allow order, notify restaurant if any item unavailable post-placement.

💳 COD Reconciliation

Cash on delivery: partner collects cash. Needs reconciliation: partner reports amount collected → matches order total. Discrepancy handling: shortage → deduct from partner wallet; excess → flag for review. Daily settlement: sum all COD orders per partner → expected amount. Digital receipt generation for each COD order. Fraud detection: pattern analysis on partner collection history.

Scaling considerations

• Redis GEO per city for partner locations (geographic sharding)
• Kafka partitioned by orderId for ordered state transitions per order
• Read replicas for restaurant browsing; primary for order writes
• CDN for restaurant images and menu photos
• City-level deployment for data locality and regulatory compliance

What interviewers expect by level

• Junior: Describe order placement flow, restaurant notification, basic delivery tracking.
• Mid: Order state machine with Kafka, WebSocket tracking, partner matching with Redis GEO.
• Senior: Dynamic ETA, restaurant availability management, COD reconciliation, handling cancellations at each state.
• Staff: Multi-city deployment, ML-based ETA with traffic, surge pricing algorithm, cost per delivery optimization.

Practice more system design case studies

• Design URL Shortener
• Design Social Media Feed
• Design Chat System
• Design Video Streaming
• Design Ride-Sharing Platform
• Design E-Commerce Platform
• Design UPI Payment Gateway
• Design Google Docs
• Design Tinder
• Design Google Drive / Dropbox
• Design Instagram
• Design Type-Ahead Search
• Design Web Crawler
• Design Ticket Booking (BookMyShow)
• Design Pastebin
• Design Notification System
• Design Rate Limiter (Standalone)
• Design Simple Web App
• Design Stock Trading System
• Design Live Streaming (Twitch)
• Design Distributed Key-Value Store
• Design Ad Click Aggregation
• Design Monitoring / Metrics (Datadog)
• Design Online Judge (LeetCode)
• Design FB Post Search
• Design Yelp
• Design Cache Layer
• Design Message Queue
• Design Full Production Stack

PrepGrind runs entirely in your browser, free, no installation required. Loading the interactive playground…