Project: ShopLite requirements and baseline architecture
60 min · Intermediate
A design document starts with requirements and numbers and ends with a plan: what the first design is, where it breaks and what to add next. This project builds ShopLite's first one as a Java program, so every number in it is calculated, not guessed.
What you'll build
ShopLite expects to grow from 1,000 to 1 million daily users. Your program prints a one-page design report: functional and non-functional requirements with targets, traffic estimates for both sizes, the one-server baseline as a diagram-in-words with its safe capacity, and the checkout request flow with a latency budget.
It ends with the growth plan for 1 million users: which change comes first and why, how many app servers the sale-day peak needs, and how much of the read traffic a cache must absorb. Every number comes from a few written assumptions, so changing one assumption updates the whole report.
=== ShopLite: requirements and baseline design ===
Functional requirements:
FR1 Customer browses and searches products
FR2 Customer places an order (UPI or card)
FR3 Customer tracks an order: PLACED, SHIPPED, DELIVERED
FR4 Admin manages products, prices and stock
Out of scope: reviews, seller marketplace, wallet
Non-functional requirements:
Latency product page p95 < 300 ms; checkout p95 < 1500 ms
Availability checkout 99.9% of each month (about 43 min down)
Consistency stock never below 0; no order charged twice
Durability a confirmed order is never lost
Scale 1 million daily users; sale-day peak 3x a normal peak
Cost start under Rs 20,000 a month
Estimate for 1000 daily users: 0.2 RPS average, 1.2 peak, 3.5 sale day; 50 orders/day
Estimate for 1000000 daily users: 231.5 RPS average, 1157.4 peak, 3472.2 sale day; 50000 orders/day
Baseline (stage 1):
[Phone/Browser] --HTTPS--> [one server: ShopLite app + MySQL] --> [Payment gateway]
Safe capacity: 280 RPS -> enough for about 241920 daily users
Single points of failure: the one server (app + data), the payment gateway
Checkout flow, baseline:
phone -> server (network) 60 ms
validate cart and address 5 ms
MySQL: check stock, insert order 25 ms
payment gateway: charge 800 ms
send confirmation email (inline) 1200 ms
server -> phone (network) 60 ms
total 2150 ms vs target 1500 ms -> TOO SLOW
with the email moved to a queue: 952 ms -> ok
Growth plan for 1000000 daily users (sale-day peak 3472 RPS):
First fix: email out of checkout (queue + worker) - it breaks the latency target at any size
Stage 2: MySQL on its own server, with a standby copy
Stage 3: load balancer x2 + 11 app servers (10 needed + 1 spare, 350 RPS each)
Stage 4: database safe limit 1400 RPS < 3472 -> cache must serve at least 60% of reads
Stage 4: CDN for product imagesRequirements
Your program should do all of these.
- The report lists four functional requirements, an out-of-scope line and six non-functional requirements, each with a target.
peakRpsturns daily users into peak requests per second from written assumptions (20 pages a visit, peak 5x the average).- Estimates print for 1,000 and 1,000,000 daily users, including the sale-day peak and orders per day.
- The baseline section shows the one-server diagram-in-words, its safe capacity at 70% CPU and the daily users it can serve.
- The checkout flow prints each hop with its milliseconds, the total against the 1,500 ms target, and the total after moving email to a queue.
- The growth plan names the first fix, then stages 2 to 4 with the number of app servers and the minimum cache hit ratio, all calculated.
Concepts you'll use
- Functional vs non-functional requirements with numbers
- Average, peak and sale-day requests per second
- A simplified CPU capacity model and the 70% safety limit
- Diagram-in-words for a single-server design
- Latency budget for one request path
- Single points of failure and bottlenecks
- Growth stages: separate database, load balancer, cache, CDN, queue
- Records for structured data in a small report program
Your plan
Build it in 5 small steps. Each step ends with a program that runs.
- Print the requirements
- Estimate traffic for both sizes
- Describe the baseline and its limit
- Trace the checkout flow with a latency budget
- Write the growth plan for 1 million users
What's next
You finished the preview of Thinking About Systems
Java Programming has 24 sections, 253 modules and 1924 lessons. An account opens every lesson and saves your progress.
Next step
Start building
5 milestones