In this lab you'll design how Tiffin tells three different people about the same order: the customer waiting for food, the kitchen cooking it, and the rider carrying it. You'll use everything from this module: topics, keys, consumer groups, delivery guarantees and the outbox.
For each step, decide for yourself first, then open the answer and compare.
The brief
Today, notifications are sent from inside the order service. When the status changes, the code calls the push provider for the customer, then the tablet service for the restaurant, then the rider app's push. It worked in one city. Now it causes trouble:
- At 8pm last Friday the push provider slowed to 2 seconds a call. Order status updates slowed to match, and the kitchen tablets stopped getting orders.
- Support gets about 30 complaints a day from customers who got "Your order is on its way" after "Delivered".
- The marketing team wants an SMS fallback when push fails, and the rider team wants to add a sound alert on the rider app. Both need changes to the order service, which its team keeps refusing.
The numbers:
| Value | |
|---|---|
| Orders | 4 million a day, 60% between 7pm and 10pm |
| Status changes per order | about 8 |
| Notifications per order | about 6 (3 to the customer, 2 to the restaurant, 1 to the rider) |
| Push provider latency | 40 ms normally, up to 2 s on bad nights |
The goal: notifications that never block ordering, almost never go missing, arrive in a sensible order, and can be extended without touching the order service.