Design Uber Eats.

Question

Design Uber Eats.

Anonymous · Accepted Answer

OPENING: SAME ANSWER, TWO FRAMINGS

If they ask “Design Uber Eats”, they’re signalling a system design question. If
they ask “We’re building a three-sided marketplace, where do we start?”, they
want to hear about people and order of work first. You use the same skeleton
either way and change the first minute.

For “Design Uber Eats”:

> “Before I draw anything I’d like to confirm what we’re optimising for. I’ll
> ask a few questions, state my assumptions, estimate the load, then sketch the
> main parts and walk one order through them. At the end I’ll cover how I’d run
> the build as a program. Please stop me wherever you’d like more depth.”

For “Three-sided marketplace, where do we start?”:

> “I’d start with the three users and what each needs, because a marketplace
> fails if any side is unhappy. Customers want food fast and a reliable ETA.
> Restaurants want orders they can prepare without chaos. Drivers want steady,
> fair earnings without waiting around. The hardest part is the chicken-and-egg
> problem: customers won’t come without restaurants, and drivers won’t come
> without orders. So I’d launch in one dense area and sign up restaurants first,
> then drivers, then open it to customers. Once we agree on that, I can walk
> through the system that supports it.”

Starting with the users shows product sense. Naming the chicken-and-egg problem
shows you understand marketplaces rather than just apps.

1. CLARIFY AND SCOPE (ABOUT 1 MINUTE)

> “A few questions. Is this one city at launch or many? Do we own the drivers or
> use a partner fleet? Are payments only digital, or cash too? Does the customer
> need live tracking on a map, or are status updates enough for version one? If
> you’re happy for me to assume, I’ll take one Indian city, our own driver
> network, digital payments, and live tracking.”

Asking about payments matters here. It sets up your strongest topic, which
you’ll come back to later.

2. ESTIMATE THE LOAD (ABOUT 1 MINUTE, EVERY STEP OUT LOUD)

> “Let me size it so the design fits the problem.”

StepWorkingResultOrders per day (assumed)One city at a mature stage50,000Busiest
hour’s shareAssume 20% of the day lands in the dinner peak0.20 × 50,000 = 10,000
orders an hourOrders per second at peak10,000 ÷ 3,600 secondsabout 3 a
secondDrivers online at peak (assumed)5,000Location updates per secondEach
driver sends GPS every 5 seconds: 5,000 ÷ 51,000 a second

> “So the interesting number isn’t orders, it’s locations: about 300 times more
> location writes than orders. Three orders a second is easy for one ordinary
> database. That tells me the hard parts are real-time location and coordination
> between three parties, not raw order volume.”

That last line is what turns arithmetic into a design decision. Interviewers
remember it.

3. THE MAIN PARTS (ABOUT 2 MINUTES, DRAW AS YOU TALK)

> “Three apps sit on top: customer, restaurant and driver. They all talk through
> one API gateway, which handles login and routing. Behind it are four core
> services, and they talk to each other through an event queue, so a change in
> an order’s status fans out to whoever cares about it.”

V

visualize

V

visualize show_widget

Then name where the data lives, with one reason for each choice:

> “Orders go in a relational database, because an order has to be consistent:
> one status, one price, one driver. Menus are read far more than they’re
> written, so they sit behind a cache. Live driver locations go in an in-memory
> store with a geographic index, because that’s the 1,000-writes-a-second stream
> and each location is stale within seconds anyway.”

The pattern is choice plus reason, three times. That’s what “trade-offs” means
to a TPM interviewer.

4. WALK ONE ORDER END TO END (ABOUT 2 MINUTES)

> “Let me follow one order, because the order’s status is the spine of the whole
> system.”

1. Placed. The customer pays at checkout. We authorize the amount, which puts a
    hold on the card without moving money yet.

2. Accepted. The restaurant has a few minutes to accept. If it doesn’t respond,
    we cancel automatically, release the hold and tell the customer.

3. Driver assigned. We don’t assign at the moment of ordering. We assign when
    the restaurant’s estimated ready time, minus the driver’s travel time, is
    close, so the driver doesn’t stand waiting. We pick by estimated travel
    time, not straight-line distance.

4. Picked up, then delivered. The driver app sends location throughout, which
    drives the live map and the ETA.

5. Completed. We capture the final amount, including any tip, and pay the
    restaurant and the driver their shares.

Then go deeper on payments without being asked, because it’s your edge in a Visa
room:

> “I’d split payment into authorize at checkout and capture after delivery.
> That’s the same split card networks use: authorization is live, while clearing
> and settlement happen later. It protects the customer if the restaurant
> cancels, because we just release the hold. Every payment call carries an
> idempotency key, so if the app retries after a timeout, the customer is never
> charged twice. And we’d use a payment gateway’s tokenization, so card numbers
> never touch our servers. That keeps most of our system out of PCI DSS scope.”

If they look interested, ask: “Shall I go deeper on payments or on dispatch?”
Checking in like this is what the Meta and Booking.com [http://Booking.com]
guides call driving the conversation.

5. WHAT BREAKS, AND THE TRADE-OFFS (ABOUT 2 MINUTES)

> “The design is only as good as how it fails, so here are the cases I’d plan
> for.”

FailureWhat we doRestaurant doesn’t accept in timeAuto-cancel, release the hold,
notify the customerTwo drivers accept the same orderThe assignment is a single
atomic write; the first one wins, the second gets “already taken”Driver’s phone
drops off the networkKeep the last known location; reassign after a
timeoutPayment gateway is downRetry with backoff, then a backup gateway; never
confirm an order without an authorizationItem runs out mid-eveningRestaurant
marks it unavailable and the menu cache is cleared for that itemDinner peak or
festival spikeThe queue absorbs bursts; stateless services scale out

Name one trade-off out loud:

> “Assigning the driver later cuts driver waiting time, but if the prep estimate
> is wrong, food sits on the counter. So prep-time accuracy per restaurant
> becomes a metric we have to watch.”

6. HOW I’D RUN IT AS A PROGRAM (ABOUT 2 TO 3 MINUTES)

This is where you separate yourself from an engineering answer. It’s the part a
TPA panel cares about most.

> “If I were the program analyst, I’d phase it so we learn early.”

* Phase 1, the core loop in one area: menus, ordering, payment, simple
   dispatch, status updates instead of a live map. We sign up restaurants first,
   then drivers, then open to customers.

* Phase 2: automated dispatch, a live map, and ETAs that learn from each
   restaurant’s prep times.

* Phase 3: batching two orders from one restaurant, promotions, ratings and
   peak-hour driver incentives.

> “Workstreams would be the three apps, the platform services, payments, and
> operations for onboarding restaurants and drivers. The critical path runs
> through payments, because of gateway integration and compliance sign-off, and
> through restaurant onboarding, because without supply there’s nothing to
> launch. Dispatch depends on the location service being ready, so those two
> teams need a shared milestone.”

> “My top risks: not enough drivers at peak, which incentives and a waitlist
> mitigate; restaurants with poor prep-time estimates; and payment failures. I’d
> track one north-star metric, orders delivered on time, with guardrails
> underneath: cancellation rate, actual against promised delivery time,
> restaurant acceptance rate, driver earnings per hour, payment success rate,
> and service availability.”

7. CLOSE (30 SECONDS)

> “To sum up: the hard parts are real-time location and coordinating three
> parties, not order volume. I’d keep orders consistent in a relational store,
> locations in memory, and connect services through an event queue. I’d
> authorize at checkout and capture on delivery. And I’d launch supply-first in
> one area, in three phases, with payments and restaurant onboarding on the
> critical path.”

LIKELY FOLLOW-UPS, WITH A ONE-LINE ANSWER EACH

* “What if traffic is ten times higher on New Year’s Eve?” Locations scale with
   drivers, not orders, so I’d shard the location store by area and pre-scale
   before the night; the order database still sees only about 30 a second.

* “Why not assign a driver as soon as the order is placed?” The driver would
   wait at the restaurant unpaid. Late assignment uses drivers better, at the
   cost of depending on prep estimates.

* “The restaurant cancels after the driver arrives. Now what?” Release the
   customer’s hold, pay the driver a cancellation fee, and count it against the
   restaurant’s reliability score.

* “How would you know the launch worked?” On-time delivery rate and repeat
   orders from week-one customers, with cancellation rate as the guardrail.

* “What would you build in three months with a small team?” Phase 1 only, in
   one area, with dispatch partly done by hand by an ops person if needed. Learn
   first, automate second.

Design Uber Eats.

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Practice More Questions