Skip to content

System design method

For a senior role, expect one 45–60 minute design round. They grade the process as much as the answer.

The six steps (say them out loud)

Step Time Do
1. Requirements 5 min Functional: the 3–5 core features. Non-functional: scale (users, QPS, data size), latency, availability, consistency needs. Ask, don't assume.
2. Estimates 3 min QPS (daily requests ÷ 86,400 × peak factor 2–5), storage per year, bandwidth. Round numbers.
3. API 5 min The main endpoints or events with inputs and outputs
4. Data model 5 min Entities, keys, which store and why (SQL vs. NoSQL vs. cache vs. object storage)
5. High-level design 10 min Boxes and arrows: client → LB → services → stores, async parts via a queue. Walk one request end to end
6. Deep dives and trade-offs 15+ min Bottlenecks, scaling, failure modes, consistency, caching, monitoring. Offer: "Which part would you like me to go deeper on?"

Numbers worth knowing

Thing Rough value
Seconds in a day ~86,400 ≈ 10⁵
1 million requests/day ~12/s average
L1 cache / RAM / SSD random read / same-DC round trip / cross-continent 1 ns / 100 ns / ~100 µs / ~0.5 ms / ~150 ms
One Postgres instance thousands to tens of thousands of simple queries/s
One Redis instance ~100,000 ops/s
One Kafka partition ~10 MB/s write, comfortably
Prayog's matching thread ~100 ns/command; fsync 0.8–12 ms

Building blocks and when to use them

Need Use Trade-off
Spread load Load balancer, stateless services, autoscaling Session state must live elsewhere
Fast reads Cache (Redis), CDN for static files Invalidation, staleness
Decouple, absorb spikes Queue / Kafka Eventual consistency, duplicates
Strong consistency, joins Relational DB Harder to scale writes
Huge scale with known access DynamoDB / Cassandra Modelling around queries
Search Elasticsearch / Lucene Another copy to keep in sync
Files S3 + pre-signed URLs
Scale writes Sharding by key Cross-shard queries, rebalancing
High availability Replicas, multi-AZ, failover Replication lag, split brain
Protect the system Rate limits, timeouts, circuit breakers, backpressure Rejected requests

Phrases that score

  • "Before I design, can I check the scale and the most important requirement?"
  • "I'll start simple and evolve it: one service and one database, then find the bottleneck."
  • "The trade-off here is…; I'd pick X because the requirement says Y."
  • "If this component fails, then…; we'd detect it with…"
  • "I'd measure before optimising." (Then cite Prayog's benchmarks.)

See worked designs for designs you can tie back to your experience.