Zomato - the case study

The whole set on one board; every scene in this lesson is drawn somewhere in it.

Boards

Before you start. You should already have a picture of a two-sided marketplace app in your head: a customer requesting something, one nearby provider, a system matching them by location. This lesson adds a third side, a kitchen, whose finishing time nobody controls, and that one difference reshapes almost everything else in this set.

The idea in 30 seconds

Zomato’s hard problem isn’t finding a rider, it’s timing one to a kitchen’s own finishing time - prep time - instead of to when the order was placed.
The one fact in the whole system nobody predicts is a human tapping “food is ready” on a tablet: ground truth, the signal every prediction is trained against and corrected by.
Deliberately waiting, then sending one rider to two nearby orders at once - batching - buys far more in extra deliveries than it costs the second customer in minutes, up to a cap.
Splitting a city into self-contained zones stops a rush in one part of town from starving the rest of it.
Search, live tracking and the money split all either feed the timing decision above or run downstream of it - none of them is really a separate problem.

Read the story · Skip to the numbers