Bird
Raised Fist0

Design a Food Delivery System - Restaurant Discovery, Order Tracking, Driver Assignment

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway

Receives user search request for nearby restaurants

API Gateway forwards search query to Search Service

Protocol:HTTP REST
BeforeUser has submitted a search query from mobile app
AfterSearch Service receives search query for processing
Search Service

Queries GeoDB for restaurants near user location

Search Service sends geospatial query to GeoDB

Protocol:Redis GET
BeforeSearch Service has user location and query parameters
AfterGeoDB returns list of nearby restaurants
API Gateway

Returns restaurant list to user

API Gateway sends search results back to client

Protocol:HTTP REST
BeforeSearch Service has restaurant list
AfterUser sees restaurant options on app
Order Service

Receives order placement request from API Gateway

Order Service validates and stores order details

Protocol:HTTP REST
BeforeUser has selected restaurant and menu items
AfterOrder is persisted and ready for driver assignment
Driver Service

Assigns available driver to new order

Driver Service selects driver based on proximity and availability

Protocol:gRPC
BeforeOrder Service has new order needing driver
AfterDriver assigned and notified of new delivery
Notification Service

Sends push notification to assigned driver

Notification Service pushes order details to driver app

Protocol:Push Msg
BeforeDriver Service has assigned driver
AfterDriver receives notification and begins delivery
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ API Gateway   │
└───────┬───────┘
        │ HTTP REST
        ▼
┌───────────────┐
│ Search Svc   │
└───────┬───────┘
        │ Redis GET
        ▼
┌───────────────┐
│    GeoDB     │
└───────┬───────┘
        │ Query Result
        ▲
        │
┌───────┴───────┐
│ Order Svc    │
└───────┬───────┘
        │ gRPC
        ▼
┌───────────────┐
│ Driver Svc   │
└───────┬───────┘
        │ Push Msg
        ▼
┌─────────────────────┐
│ Notification Svc    │
└─────────────────────┘
Design Rationale

This architecture diagram illustrates the vertical flow of a food delivery request starting from the API Gateway, which acts as the client entry point. The Search Service queries the GeoDB to discover nearby restaurants, returning results back through the API Gateway to the user. Once the user places an order, the Order Service processes and stores the order. It then communicates with the Driver Service via gRPC to assign an available driver based on proximity. Finally, the Notification Service sends a push notification to the assigned driver to initiate delivery. This vertical pipeline emphasizes clear separation of concerns and protocol usage optimized for each step, ensuring scalability and maintainability.

Primary Focus

✓

Practice

(1/5)
1. Without a partition-tolerant message queue like Kafka, what exactly breaks in a distributed chat system during a network partition?
medium
A. Alice's send blocks until Bob's server responds -- if Bob's server crashes, message is lost with no retry
B. Messages are duplicated multiple times causing inconsistent chat history
C. Messages are delivered out of order but eventually arrive
D. The system automatically switches to a backup server maintaining availability

Solution

  1. Step 1: Understand role of partition-tolerant queue

    Kafka decouples sender and receiver, buffering messages during partitions.

  2. Step 2: Trace failure without Kafka

    Without Kafka, sender blocks waiting for receiver; if receiver crashes, message is lost with no retry.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Without Kafka, sender blocks and loses messages if receiver crashes [check]
Hint: No Kafka -> sender blocks and loses messages if receiver crashes [check]
Common Mistakes:
2. If Kafka becomes unavailable, what exactly breaks in the real-time analytics pipeline?
medium
A. Flink jobs continue processing from last checkpoint without data loss
B. Dashboard queries return stale data but ingestion continues normally
C. Event ingestion blocks causing upstream producers to backpressure and data loss risk
D. OLAP store automatically switches to batch ingestion mode without downtime

Solution

  1. Step 1: Understand Kafka's role in ingestion and buffering

    Kafka buffers incoming events; if unavailable, ingestion halts causing backpressure upstream.

  2. Step 2: Trace downstream impact

    Flink cannot consume new events, so dashboards show stale data; OLAP store remains unaffected initially.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka outage causes stale dashboard data due to halted ingestion [check]
Hint: Kafka outage stalls ingestion, dashboards show stale data [check]
Common Mistakes:
3. If the spam detection service becomes unavailable, what is the most likely failure mode affecting the Q&A feed?
medium
A. The feed service crashes due to unhandled exceptions from missing spam data
B. Spam scores default to zero, causing spammy content to appear in feeds without filtering
C. All new questions and answers are blocked until spam detection recovers
D. Users see delayed feed updates but spam filtering continues normally

Solution

  1. Step 1: Analyze spam detection dependency

    Blocking all writes (A) is too strict; defaulting scores (B) risks spam but is safer; delayed updates (D) unlikely if spam data is missing.

  2. Step 2: Unhandled exceptions cause crashes

    If the feed service does not handle missing spam data gracefully, it crashes (C), causing feed unavailability and degraded user experience.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing spam data causes unhandled exceptions and feed crashes [check]
Hint: Unhandled missing spam data crashes feed service [check]
Common Mistakes:
4. At 10x scale, which component is most likely to fail first due to stateful connection limits, and why?
hard
A. The chat servers, because WebSocket connections are stateful and cannot be resharded easily
B. The message queue, because partition count limits throughput
C. The database cluster, because query volume exceeds CPU capacity
D. The load balancer, because it cannot distribute traffic evenly at high scale

Solution

  1. Step 1: Identify stateful bottleneck

    Chat servers maintain WebSocket connections bound to server memory, limiting horizontal scaling and resharding.

  2. Step 2: Compare other components

    Database (A) can be scaled with sharding; message queue (C) partitions can be increased; load balancer (D) scales horizontally.

  3. Step 3: Explain failure mechanism

    WebSocket statefulness causes connection limits per server, leading to failure under 10x load.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Stateful WebSocket limits -> chat servers fail first at scale [check]
Hint: Stateful WebSockets limit scaling; stateless scale easier [check]
Common Mistakes:
5. At 10x scale, which component of a distributed HyperLogLog-based unique user counting system is most likely to fail first, and why?
hard
A. The aggregator node, because it must merge many HyperLogLog sketches and becomes CPU-bound
B. The HyperLogLog register storage, because fixed-size registers cannot represent larger cardinalities accurately
C. The network bandwidth between servers, because merging large raw user ID sets saturates links
D. The user ID ingestion layer, because it must hash and update many HyperLogLog sketches concurrently

Solution

  1. Step 1: Analyze scaling impact on components

    Network bandwidth is low since only fixed-size sketches are transferred, not raw IDs; register size is fixed and does not fail but accuracy degrades slightly.

  2. Step 2: Identify bottleneck

    The aggregator merges many sketches concurrently, increasing CPU load and latency, making it the first to fail under 10x load.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Aggregator CPU-bound merging many sketches first bottleneck [check]
Hint: Aggregator CPU merges many sketches -> first bottleneck [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard