Katkat
Back

Design Food Delivery Cart

UberSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a distributed, highly concurrent shopping cart service for a food delivery platform, focusing on transactional integrity, race conditions, and eventual consistency.

Problem Statement

Design a high-scale shopping cart service for a food delivery platform like Uber Eats. The system must support millions of concurrent users adding, removing, and updating items across multiple restaurant storefronts.

Functional Requirements

  • Users can add items (with customizations like 'no onions' or 'extra cheese') to a cart.
  • Users can update quantities or remove items.
  • The system must calculate a real-time subtotal, including item-level prices and restaurant-level service fees.
  • Cart state must be persisted so users can switch devices seamlessly.

Non-Functional Requirements

  • Concurrency: Ensure that rapid clicks by a user don't lead to race conditions (e.g., adding the same item twice).
  • Latency: Cart updates should be sub-100ms.
  • Reliability: Cart data should not be lost during server restarts.
  • Scalability: The system must handle high traffic during peak hours (e.g., Friday night).

Discussion Points

  1. Data Model: How would you schema the items, customizations, and prices? Should this be in a relational database, NoSQL, or a distributed cache?
  2. Concurrency/Idempotency: How do you prevent duplicate actions if the client retries a request due to a network timeout?
  3. Pricing Logic: How do you handle price changes? If a restaurant changes a price while an item is in the user's cart, how should the system handle it during checkout?
  4. Scalability: How would you handle a sudden surge in traffic during a promotional event?

Hints

Hint 1

Consider using an idempotent key (e.g., a client-side generated UUID for each action) to prevent duplicate additions in the event of retries.

Hint 2

Decide whether to use a cache-aside pattern with a fast key-value store (like Redis) for low latency, backed by a persistent database for durability.

Hint 3

Think about the trade-offs of storing pricing snapshots at the time of addition versus recalculating totals on every cart fetch.

Follow-up questions

  • How would you integrate a real-time promotion engine that applies discounts (e.g., '20% off') without complicating the core cart data model?
  • If the cart needs to be shared among multiple users (e.g., group ordering), what changes are needed to your locking strategy?
  • How would you handle a scenario where an item becomes unavailable (sold out) after it has already been added to a user's cart?