How do I calculate QPS (queries per second) in a system design interview?

Use the formula: QPS = (Daily Active Users × average requests per user per day) / 86,400 seconds. Then estimate peak QPS as 2–3x the average (traffic is not uniform — peak usually occurs during evening hours or news events). For example: 10M DAU × 5 reads/day / 86,400 = ~579 QPS average, ~1,750 QPS peak. Always state your assumptions explicitly. Interviewers are evaluating your estimation process as much as the number itself. Round aggressively (86,400 ≈ 10^5) to keep the math fast.

When should I use NoSQL instead of SQL in a system design?

Choose NoSQL when: (1) Write throughput is extreme (100,000+ writes/second) and horizontal scaling is required — SQL sharding is complex while DynamoDB or Cassandra scale horizontally by design. (2) Your access pattern is simple key-value or document lookups with no joins — NoSQL is optimized for these. (3) Schema is highly variable (different documents have different fields). (4) You need global geographic distribution with low-latency reads. Stick with SQL when: you need ACID transactions across multiple records (financial systems), complex queries with JOINs are required, your team is more familiar with relational modeling, or you are at a scale where SQL is sufficient (below ~50,000 QPS on a well-tuned instance with read replicas).

What is the CAP theorem and why does it matter for system design?

CAP theorem states that a distributed data store can guarantee at most two of three properties: Consistency (every read returns the most recent write), Availability (every request receives a non-error response), and Partition Tolerance (the system continues functioning when network partitions occur). Since network partitions are inevitable in any distributed system, the real trade-off is between Consistency and Availability. CP systems (PostgreSQL, HBase, ZooKeeper) prioritize correctness — they may refuse requests during a partition rather than serve stale data. AP systems (Cassandra, DynamoDB, CouchDB) stay available during partitions but may serve stale data. In system design interviews, justify your database choice by stating which trade-off your use case requires: financial systems need CP, social feeds can accept AP.

How would you design a system for 10 million users that needs to scale to 100 million?

Start with the simplest architecture that handles 10M users: a single primary database with read replicas behind a load balancer, Redis cache for hot data, a CDN for static assets. Calculate your QPS at 10M and 100M users. At 10M with typical SaaS usage (10 requests/day/user), that is ~1,160 QPS — manageable with a single well-tuned Postgres instance plus read replicas. At 100M users, you hit ~11,600 QPS, which still fits with aggressive caching and read replicas. If writes become the bottleneck, add database sharding. Introduce message queues for async work early. Plan for 100M from the start in your architecture, but do not over-engineer for it — deploy the simple version first and scale components as actual bottlenecks emerge.

What is consistent hashing and when is it used?

Consistent hashing is an algorithm that minimizes the number of key remappings when nodes are added or removed from a distributed system. In a regular hash (key % num_nodes), adding one node requires remapping ~50% of all keys. With consistent hashing, adding or removing a node remaps only key_count / num_nodes keys on average — typically a small fraction. The algorithm maps both keys and nodes to positions on a circular ring (0 to 2^32). Each key is assigned to the next node clockwise on the ring. Use consistent hashing for: distributed caches (deciding which cache server holds a given key), database sharding with dynamic cluster size, and distributed load balancing (directing user sessions to the same server for sticky sessions). Most distributed caches (Redis Cluster, Memcached) and databases (Cassandra, DynamoDB) use consistent hashing internally.

Engineering·14 min read·June 20, 2026

🏗️ System Design Interview Guide: Architecture Patterns and Trade-offs

A complete system design interview guide covering the RESHADED framework, back-of-envelope estimation, load balancing, caching strategies, database scaling, message queues, CDN, and rate limiting — with worked examples for URL shortener and social feed designs.

📖Full-Stack SaaS with Next.js, Supabase & Groq AI (Full Access)

View →

The Interview Framework: What Interviewers Are Actually Testing

System design interviews are not tests of memorized architectures. They are evaluations of how you think under ambiguity, how you quantify trade-offs, and whether you can have a structured technical conversation. Interviewers want to see you clarify scope, estimate scale, justify decisions, and identify bottlenecks — not recite a pre-memorized "correct answer."

Use this framework for every interview, and make your process explicit as you go:<

Topics covered

system design interviewsystem design guideback-of-envelope estimationCAP theorem explaineddatabase sharding strategiesload balancing algorithmsRedis caching patternsmessage queue Kafka vs RabbitMQURL shortener system designsocial feed architecturefan-out on write vs readconsistent hashingdatabase read replicasCDN architecturerate limiting token bucketsystem design trade-offsSQL vs NoSQL when to useQPS calculationdistributed systems patternsBASE vs ACID database