E-commerce: 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 — Rails monolith + Postgres + Stripe checkout
1. Current architecture
Where we are before growth pressure
3 × c6i.large Rails apps + Postgres db.r6i.large + Redis cache + Stripe checkout. Tables: `products, orders, order_items, users, carts`. Every request hits Postgres. Sidekiq for async jobs (emails, receipts). Stripe handles payment.
2. Growth trigger
What changed — the traffic/data force
MVP launch. 100K DAU. Peak 10K RPS mostly product-browse. Average cart 2-3 items. ~50 orders/minute peak. Traditional 9-to-5 shopping pattern.
3. Bottleneck — what breaks FIRST?
The component that saturates as growth arrives
None yet — Rails + Postgres handles this comfortably
10K RPS with proper indexing on products + Redis cache for product data = Postgres at 30% CPU. Cart in Redis (fast). Checkout via Stripe API (external). p99 page load: 200-500ms. Well within typical e-commerce SLA.
Postgres CPU 30%, Redis hit rate 90%, order checkout latency p99 800ms (Stripe-dominated), conversion rate 2.5% (industry avg)
4. Options — what could we do?
Alternatives an architect must consider before picking
- + Simplest possible architecture
- + Fast iteration (Rails productivity)
- + Stripe handles payment complexity + PCI compliance
- + Team ships fast
- − Postgres single-primary SPOF
- − Ceiling around 30-50K RPS on this stack
- − No flash-sale defense (yet)
5. Chosen
The specific decision we're making
Do nothing — Rails monolith is right at 10K RPS
6. Trade-offs
What we're explicitly accepting to move forward
- Accept single Postgres SPOF (60s failover)
- Accept ceiling around 30-50K RPS
- Accept no flash-sale defense (rare at this scale)
- Accept Stripe as payment vendor (~2.9% + $0.30 per transaction)
7. New architecture
The system after this decision — headroom for the next 5-10x
3 Rails apps + Postgres + Redis + Sidekiq + Stripe. Total cost: $600/mo. Shopify-style stack.
8. Next bottleneck — what will break at the NEXT rung?
This is the seed of the next rung
At ~100K RPS during first flash-sale (Black Friday + 1M user launch + celebrity mention), Postgres write bottleneck cripples checkout. Also inventory oversell risk (race condition on limited-stock items). L5 shape.
What comes next in your Junior → Architect journey
You've traced 6 rungs of E-commerce 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.