Lab: The first version of the food app

Time to put the whole module together. In this lab you'll design version one of Tiffin, from the brief to a design you could start building on Monday.

Each step asks you to decide something first. Try it before opening the answer. Your answer doesn't have to match; what matters is that you can say why you chose what you chose.

The brief

Three founders and two engineers want to launch Tiffin in one city in 10 weeks. Here's what they tell you:

• At launch they've signed 300 restaurants, aiming for 800 by the end of the first year.
• They expect 5,000 orders a day at launch, and hope for 50,000 a day within a year.
• Customers order from one restaurant at a time, pay by card or UPI, and get food delivered by Tiffin's own riders.
• Each restaurant gets a cheap Android tablet in the kitchen.
• "Customers must never be charged for an order the restaurant never sees."
• "We can't afford a big infrastructure bill, or a team to run it."

Step 1: Requirements

Turn the brief into a short list of functional and non-functional requirements. Also decide what is not in version one.

The "not in version one" list is as important as the rest. Each item on it is something you'd otherwise half-build. Live tracking, for instance, needs a whole new way for the server to talk to phones (Module 6). Automatic rider assignment is a hard problem of its own. A human with a dashboard can assign 5,000 orders a day across a few shifts, and will learn what the algorithm should do.

Step 2: Numbers

Design for the end of year one, not launch day: 50,000 orders a day and 800 restaurants.

It's worth saying the conclusion out loud, because people find it hard to believe: the whole of Tiffin's first year fits on two machines. One for the app, one for the database (a managed PostgreSQL service, so nobody on a five-person team has to babysit backups). That also answers the founders' cost worry. Two decent cloud machines cost a few hundred dollars a month.

We'll put photos in object storage from day one. It costs nothing extra in effort, and the estimate showed photos are the biggest source of bandwidth.

Step 3: The API

GET   /v1/restaurants?lat=..&lng=..&cursor=..
GET   /v1/restaurants/{id}/menu
POST  /v1/orders                              (not safe to retry)
POST  /v1/orders/{id}/payment                 (not safe to retry)
GET   /v1/orders/{id}
GET   /v1/me/orders?cursor=..

GET   /v1/restaurants/{id}/orders?status=placed   (tablet polls)
POST  /v1/orders/{id}/accept
POST  /v1/orders/{id}/reject
POST  /v1/orders/{id}/ready
PATCH /v1/menu-items/{id}                     ({"is_available": false})

GET   /v1/me/deliveries
POST  /v1/deliveries/{id}/picked-up
POST  /v1/deliveries/{id}/delivered

{
  "restaurant_id": 42,
  "items": [{ "menu_item_id": 7, "quantity": 2 }],
  "delivery_address_id": 5
}

A few decisions to check against yours:

• Version in the URL from day one (/v1). Old app versions will be around for years.
• Cursor pagination on the restaurant list and order history.
• Status changes are named actions. POST /orders/{id}/accept lets the server check the order is still placed and belongs to this tablet's restaurant.
• One error format with a stable code, so the app can show "this dish just sold out" instead of a generic failure.

The two calls marked "not safe to retry" deserve a note. If a customer taps "Pay" on a weak signal and the app retries, we must not charge twice. The proper fix is an idempotency key (Module 12). For version one, a simple guard covers most of it: the server refuses a payment for an order that already has a successful one.

Here's one order's happy path through those endpoints, from placing it to the kitchen accepting it:

%% caption: One order, placed, paid and accepted. The kitchen learns about it by polling.
sequenceDiagram
  autonumber
  participant C as Customer app
  participant S as App server
  participant D as PostgreSQL
  participant P as Payment provider
  participant K as Kitchen tablet
  C->>S: POST /v1/orders
  S->>D: insert order and items
  S-->>C: the order, with server prices
  C->>S: POST .../payment
  S->>P: charge
  P-->>S: success
  S-->>C: paid
  K->>S: poll placed orders, every 5 s
  S-->>K: the new order
  K->>S: POST .../accept
  S->>D: update only if still placed
  S-->>K: accepted

Step 4: The data model

Now the hardest non-functional requirement: "never charge for an order the restaurant never sees." How does the model support it?

The order is saved before the customer is charged, with status pending_payment. Only when the payment provider confirms do we flip it to placed, in the same transaction that records the payment:

BEGIN;
UPDATE payments SET status = 'succeeded', provider_ref = :ref
  WHERE id = :payment_id;
UPDATE orders SET status = 'placed', updated_at = now()
  WHERE id = :order_id AND status = 'pending_payment';
COMMIT;

Kitchen tablets only see placed orders. So there's never a moment where money was taken but no order exists for the kitchen to see. (What if the server crashes between the provider charging the card and this transaction? Payment providers send a confirmation callback, called a webhook, which retries until we acknowledge it. That callback runs the same transaction. Handling all of this properly across services is Module 16.)

So our status list grows one value: pending_payment, before placed.

Step 5: Indexes

The tablet query is the one to get right. It runs every 5 seconds from every restaurant, all day, and without its index it would scan the whole orders table, which grows by 50,000 rows a day.

The restaurant list is the awkward one. "Open restaurants near this location" means filtering by distance. With only 800 restaurants, the simplest answer is to load all open restaurants (a few hundred rows) and compute distance in the query. It's fast at this size. Proper geographic indexes are a topic for Module 19.

Step 6: Two people, one order

Here's a race that will happen within the first week. At 8:14pm the customer taps "Cancel". At the same second, the kitchen taps "Accept". Both requests reach the server at once.

-- Kitchen accepts
UPDATE orders SET status = 'accepted', updated_at = now()
WHERE id = 9481 AND status = 'placed';

-- Customer cancels
UPDATE orders SET status = 'cancelled', updated_at = now()
WHERE id = 9481 AND status = 'placed';

This pattern, "update only if it's still in the state I expect", is one of the most useful in all of system design. It needs no locks in your code (the database's own brief row lock does the work) and works no matter how many requests arrive at once.

The final design

%% caption: Tiffin version one. Two machines and two managed services, sized for the first year.
flowchart TD
  CA(["Customer app"]) --> S
  KT(["Kitchen tablet"]) -- "polls every 5 s" --> S
  RA(["Rider app"]) --> S
  S["App server<br/>API, rules, payments"]:::hot --> PG[("PostgreSQL<br/>orders, menus, everything")]:::store
  S --> PP["Payment provider<br/>card and UPI"]
  S --> OS[("Object storage<br/>dish photos")]:::store

And what we deliberately left out, with the trigger that would bring each one in:

That table is a design too. It says you've thought about growth, and chosen not to pay for it until it arrives.

Build it on AWS

The founders said two things that decide the AWS design: "we can't afford a big bill" and "we can't afford a team to run it". The first pushes towards small. The second pushes towards managed services, even where they cost a little more, because five people shouldn't be patching database servers. From here on, Tiffin runs in Mumbai (ap-south-1), and prices are Mumbai on-demand list prices as of late 2026. They differ from other Regions, so check the AWS pricing calculator before quoting them.

The architecture

%% caption: Tiffin version one on AWS. Two small containers, one managed database, photos at the edge.
flowchart TD
  CA(["Customer app"]) --> ALB["Application Load Balancer<br/>TLS, health checks"]
  KT(["Kitchen tablet"]) --> ALB
  RA(["Rider app"]) --> ALB
  CA -- "dish photos" --> CF["CloudFront"] --> S3[("S3<br/>dish photos")]:::store
  ALB --> API["ECS on Fargate<br/>2 tasks, Graviton, 2 zones"]:::hot
  API --> PG[("RDS for PostgreSQL<br/>Multi-AZ")]:::store
  API --> PP["Payment provider"]

Argument 1: the lab said one server. Why two tasks and a load balancer?

On Fargate, "the server" is a task, and a task gets a new private IP address every time it restarts or is deployed. Something has to give the apps a stable address and drop dead tasks from rotation, and that's the load balancer's job. Once it's there, a second task is cheap, and it buys two things the founders care about: deploys stop being outages, and one dead task (or a whole Availability Zone) doesn't take Tiffin down. By default, an ECS rolling deploy starts each new task before it stops an old one.

Size the tasks from the lab's own numbers: about 200 simple requests a second per core, and a year-one peak of 500. At launch, two tasks of 1 vCPU and 2 GB are plenty. By the end of the year, two tasks of 2 vCPU and 4 GB keep the peak around 60% of capacity. Changing the size is a task definition change and a rolling deploy, with no downtime.

Two settings are worth getting right on day one:

• Build Arm images. In Mumbai, Fargate on Graviton costs $0.02383 per vCPU-hour against $0.04256 for x86, about 44% less. At year-end size that's roughly $85 a month instead of $150, for a one-line change to the build.
• Check the Fargate quota now. The default is 6 on-demand vCPUs per Region, and new accounts can start lower. Two 2-vCPU tasks fit, but a rolling deploy wants to run four at once, and 8 vCPUs is over the quota: only one new task can start at a time, so every deploy crawls and logs launch failures. Request an increase before it bites. It costs nothing.

Argument 2: Single-AZ or Multi-AZ, on day one?

The brief says "a paid order is never lost". Compare the two RDS options against it:

db.m7g.large, Single-AZ:  $0.240/hour = ~$175 a month
db.m7g.large, Multi-AZ:   $0.479/hour = ~$350 a month

Single-AZ already has backups, with transaction logs uploaded every five minutes. But if the instance's storage fails, the restore can lose up to five minutes of commits. At the year-one dinner peak of about 3 orders a second, that's up to 900 paid orders whose records are gone, to be rebuilt by hand from the payment provider's reports.

Multi-AZ keeps a synchronous standby in another zone, so a committed order is already on two machines. If the primary fails, RDS moves the database's DNS name to the standby, typically within 60 to 120 seconds. The app must reconnect, so make sure the database driver retries connections instead of crashing. The standby can't serve reads. It exists only to take over.

For a company that takes money, $175 a month is the cheapest insurance on the bill. Turn Multi-AZ on before launch. Start on db.m7g.large, and move to db.m7g.xlarge when dinner-time CPU passes about 60%. Changing the instance class on a Multi-AZ database triggers a failover, so do it at 4am.

Argument 3: what will actually dominate the bill?

Not the servers. The estimation lesson found photo traffic of about 1.2 MB per session. CloudFront in India charges $0.109 per GB for the first 10 TB, and $0.012 per 10,000 HTTPS requests, after a free 1 TB and 10 million requests a month:

At launch:   15,000 sessions x 1.2 MB = 18 GB a day = 540 GB a month   -> inside the free tier
             about 40 images a session = 18M requests a month          -> ~$10
Year one:    150,000 sessions x 1.2 MB = 180 GB a day = 5.4 TB a month
             data: (5,400 - 1,000 free) GB x $0.109                   = ~$480
             requests: 180M - 10M free = 170M x $0.0000012            = ~$200
                                                                        ~$680 a month

By the end of year one, dish photos cost more than the database. That makes image size a cost decision. Serving small WebP thumbnails on list screens instead of full photos can halve the line, which is worth a day of an engineer's time.

What it costs

At 1.5 million orders a month, the year-one bill is under a tenth of a cent per order. One thing isn't in the table: tasks in private subnets need a NAT gateway to reach the payment provider, and it has its own hourly and per-GB charge in each zone. For a system this small it can cost more than the two tasks, so price it before you add one.

The same design on GCP and Azure

One real difference at this size: Cloud Run and Container Apps give each service its own HTTPS address, so a tiny system can start without a separate load balancer.