Food Delivery: Junior → Architect Evolution
The mandated interactive flow. Step through each rung, ask what breaks FIRST, weigh the options, and defend the chosen architecture. This is how architectural thinking is learned — not by reading a fixed design, but by tracing how it evolves under growth pressure.
Scale Evolution Timeline
Step through 6 architectural rungs, from 10K RPS to 1B RPS. At each rung, ask: what will break FIRST? Why? What options exist? Which one do we pick — and what are we accepting?
This is the reasoning cycle that separates a Junior developer ("here's an architecture") from an Architect ("here's why this architecture, why now, and what breaks next").
10K RPS — single-city PostGIS + Twilio SMS
1. Current architecture
Where we are before growth pressure
3 × c6i.large Rails apps + Postgres db.r6i.large with PostGIS extension. Restaurants + orders + drivers all in one DB. Discovery: PostGIS `ST_DWithin` for 'restaurants within 5km'. Order tracking via Twilio SMS ('driver picked up').
2. Growth trigger
What changed — the traffic/data force
MVP in one city (say Boston). 500 restaurants, 100 drivers, 10K orders/day. Peak 10K RPS during 6-8pm dinner rush.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — PostGIS + Rails handles single-city
PostGIS + spatial index (GiST) does 'restaurants near me' in 20-40ms. 500 restaurants + 100 drivers fit in Postgres at 30% CPU. Twilio SMS for tracking is $0.0075 per message × 10K orders × 5 messages = $375/month. Sub-second responses for all queries.
Postgres CPU 30%, PostGIS query 25ms p99, order-to-driver dispatch time 90s (mostly manual), delivery time avg 32 min
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Zero new infrastructure
- + Team ships fast (Rails productivity)
- + PostGIS handles single-city geo queries well
- + SMS is universal (no app dependency for tracking)
- − Doesn't scale past 1 city (PostGIS + single Postgres = ceiling)
- − Manual driver dispatch doesn't scale past 500 drivers
- − No real-time tracking UI (SMS only)
- − No customer preferences or recommendations
5. Chosen
The specific decision we're making
Do nothing — Rails + PostGIS is right for 1-city MVP
6. Trade-offs
What we're explicitly accepting to move forward
- Accept single-city ceiling (need multi-tenancy for expansion)
- Accept manual driver dispatch (dispatcher on-call)
- Accept SMS-only tracking (no map UI)
- Accept no personalization (everyone sees same restaurants)
7. New architecture
The system after this decision — headroom for the next 5-10x
3 Rails + PostGIS Postgres + Twilio SMS. Total cost: $700/mo (mostly SMS).
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~100K RPS with 10 cities + WhatsApp/SMS tracking limits, PostGIS single-primary bottleneck + manual dispatch needs automation. Also customers want live map tracking. Redis geohash + auto-dispatch + WebSocket tracking — L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of Food Delivery evolution. Now try the same reasoning cycle on a system you don't know yet — pick from the Systems catalog and answer the same questions: current arch → growth trigger → bottleneck → options → chosen → trade-offs → new arch → next bottleneck. That is architecture.