Skip to content
All problems

Live delivery-partner tracking for a food-delivery order

EasyAbout 30 minutes

Before you start:API Paradigms: REST vs GraphQL vs gRPC

Your attempt

A complete grade of 70 or more solves it.

A food-delivery app lets a customer watch their delivery partner move toward them on a map while an order is out for delivery. Unlike a stadium chat room, nobody else is watching the same delivery: a customer's tracking screen is theirs alone. You are designing the realtime side that carries a location from a delivery partner's phone to the one customer waiting on it.

What tracking does

  • A customer watching an order keeps a WebSocket open to the gateway fleet and sees the delivery partner's location move on a map.
  • A delivery partner's app posts a location update every few seconds over plain HTTP; the gateway fleet delivers it to the one customer watching that order, and nobody else.
  • A customer who opens tracking after updates have already started sees the most recent known location at once, not a blank map.

The numbers

  • During a lunch or dinner rush, about 40,000 deliveries are being tracked at once, each posting a location roughly every ten seconds. At the peak of a big match or festival night, tracked deliveries roughly triple, to about 120,000 at once.
  • Writing one frame to one socket costs about 20 µs of CPU on the gateway. Accepting a connection (TLS and authentication) costs about 2 ms.
  • Set frame_us and handshake_ms on the gateway to match, and fan_out to how many sockets one update actually reaches.
  • Behind the gateway, a tracking service records each update and refreshes the last known location for about 1 ms of CPU; set its write_cpu_ms to match.
  • The gateway places each new connection on the instance holding the fewest, and a rolling deploy restarts one instance at a time. The customer app spreads its reconnects over about ten seconds after a drop; set reconnect_jitter_s to match.

What good looks like

A location update reaches the watching customer's socket within 200 ms at p99, and at most 1 update in 1,000 fails to be delivered. The same holds at the peak of a big event night and while the gateway fleet is redeployed one instance at a time.

Where to start

This is not a broadcast problem: work out the difference between how many updates arrive a second and how many connections must be held open at once. One drives frame-writing CPU, which is small here; the other drives how much connection capacity the fleet needs, and that is where an event night actually bites. Then size the service behind the gateway for the event night's updates, and give each gateway instance the cores to take a restarted neighbour's reconnects.

Out of scope: the map rendering itself, route and ETA calculation, and how a customer is matched to their order's tracking channel.

Requirements

Functional

  • A customer watching an order out for delivery keeps a WebSocket open to the gateway fleet and sees the delivery partner's location move on a map.
  • A delivery partner's app posts a location update every few seconds over plain HTTP; the gateway fleet delivers it only to the one customer watching that order.
  • A customer who opens tracking after the delivery partner has already sent updates sees the most recent known location at once, not a blank map.

Non-functional

  • Almost every active delivery has at most one customer watching it, unlike a broadcast to a crowd; the cost here is the number of open connections, not fan-out.
  • The gateway fleet is deployed during the day, so a rolling deploy while deliveries are under way is routine and must not be noticed.
  • A customer who loses their connection (a lift, a tunnel, switching networks) reconnects and keeps seeing updates without refreshing the app.
  • When a gateway instance restarts, the customer apps it held spread their reconnects over about ten seconds, not all at once.

Estimation

Before you draw, estimate these. The workspace checks each answer against its band as you type.

  1. Location updates per second during a lunch or dinner rush (updates/s)
  2. Frames the gateways write per second (frames/s)
  3. Gateway cores busy with frame-writing on a big event night (cores)
  4. Tracking-service instances for the peak of a big event night (instances)
  5. Handshakes per second while one of eight instances restarts (handshakes/s)

Tests

2 sample tests you can read and run

  • Location updates are delivered quickly during a rush (Performance)
  • A location update reaches only the one customer watching that order (Functionality)

4 hidden tests, graded when you submit

  • Scalability1
  • Reliability3

What the design must meet

Service levels

  • A location update reaches the watching customer's socket within 200 ms at p99.
  • At most 1 update in 1,000 fails to be delivered, deploys included.

Load

  • During lunch and dinner rushes, about 40,000 deliveries are being tracked at once, each posting a location roughly every ten seconds.
  • At the peak of a big match or festival night, tracked deliveries roughly triple, to about 120,000 at once posting about 12,000 updates a second.

How an attempt runs

  1. RequirementsWhat the service must do, and the numbers it must meet
  2. EstimateSize the load before you draw
  3. DesignBuild it on the canvas and run traffic through it
  4. TestRun the sample tests in your browser
  5. SubmitThe hidden tests grade the design