Katkat
Back

Design a Food-Delivery Backend (Uber Eats-style)

UberSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem evaluates your ability to design a distributed system that manages real-time interactions between three distinct user types: customers, restaurants, and couriers, with a focus on geospatial querying and high-concurrency event streaming.

Problem Statement

Design a backend architecture for a food-delivery platform similar to Uber Eats. Your solution must support the following core features:

  1. Geospatial Discovery: Users should be able to view restaurants within a specific radius of their current location.
  2. Order Management: A workflow to handle order placement, restaurant confirmation, courier assignment, and status updates (e.g., preparing, picked up, delivered).
  3. Real-time Tracking: Customers must see the courier's location updated in near real-time on the map.

Scale Assumptions

  • Daily Active Users: 10 million.
  • Peak Orders: 50,000 per minute.
  • Courier location updates: Every 3-5 seconds per active courier.

Your Deliverables

  • API Design: Define the core REST or gRPC endpoints for the user and courier applications.
  • Data Model: Propose a database schema (SQL vs. NoSQL) to store restaurant data, order states, and courier locations.
  • High-level Architecture: Provide a diagram or flow description identifying key microservices, message queues, and caching layers.
  • Geo-indexing: Explain how you would efficiently query restaurants near a user and match orders with available couriers.

Example Scenarios

  • Order Flow: A customer places an order; how does the system notify the restaurant and search for the nearest available courier?
  • Concurrency: How do you prevent "double-assignment" of a single courier to multiple orders simultaneously?

Hints

Hint 1

Consider using a geospatial index like Geohashes or Quadtrees to partition the map and efficiently query nearby entities.

Hint 2

Decouple the order placement flow from the courier matching process using an asynchronous message broker like Kafka to ensure system resilience.

Hint 3

For live tracking, utilize a high-throughput, low-latency store like Redis (using Geohash sets) to cache and serve volatile location data.

Follow-up questions

  • How would you handle a sudden surge in demand during peak hours (e.g., Super Bowl Sunday) to ensure the system doesn't crash?
  • If a courier's GPS signal is lost or intermittent, how would you design the system to handle 'location gaps' for the customer's view?
  • How would you implement a fair dispatch algorithm to ensure couriers are assigned orders efficiently while balancing their earnings?