Tiffin now runs in ten cities. The app is a modular monolith (Module 9): clear modules, owning teams, boundaries checked in the build. Search was split out into its own service last year and that went well. Now leadership asks: what's next to carve out, and how do we do it without an outage?
In this lab you'll pick the next service, define its boundary, plan the migration step by step, and decide how it behaves when it fails. Decide each step yourself before reading on.
The brief
| Fact | Value |
|---|---|
| Orders a day | 400,000 |
| Riders on shift at dinner | ~15,000, each sending a location every 4 s |
| Engineers | 60, in 8 teams |
| Monolith instances at dinner | 40 |
| Monolith deploys | Twice a day, about 25 minutes each |
| Incidents last quarter | 5, three of them during a deploy |
And some observations the teams have collected:
- Rider location pings arrive at 3,750 a second at dinner, and handling them takes about 75% of the monolith's CPU. Each ping passes through the monolith's full stack (middleware, auth, session checks) just to do one Redis write. Most of those 40 instances exist to absorb pings, not to serve customers.
- Every monolith deploy restarts instances, which drops riders' connections. Thousands of riders reconnect at once, twice a day. Two of the three deploy incidents started this way.
- The logistics team owns location and dispatch. They want to tune how often riders ping and how "riders near this restaurant" is calculated, and they're waiting on the shared deploy to try anything.
- The payments team wants to deploy more carefully, with longer canaries, and finds the shared deploy too fast.
- Notifications are already sent by background workers and almost never cause trouble.