InterviewGrind Get notified

InterviewGrind › System design

System Design Interview Questions and Answers

Caching, sharding, queues, back-of-the-envelope estimates and the trade-offs behind them: system design interview questions you can practise in five minutes, each with the reasoning an interviewer wants to hear.

15 free questions from the app. Try each one before you open the answer.

1. CachingEasy

You added a cache for user profiles. Now users say their profile looks unchanged right after they edit it. Most likely cause?

  1. The database is losing writes under load
  2. The cache isn't invalidated when the profile changes
  3. The load balancer sends reads to a slow server
  4. The browser renders the profile before the write finishes
Show answer

Answer: B. The cache isn't invalidated when the profile changes

Reads hit the old cached copy until it expires. On write, delete (or update) the cache entry. Deleting is usually safer than updating, because two concurrent updates can leave the cache holding the older value.

2. Back-of-envelopeEasy

One million daily active users each keep a 2 KB session in Redis. Roughly how much memory is that?

  1. About 2 MB
  2. About 2 GB
  3. About 200 GB
  4. About 2 TB
Show answer

Answer: B. About 2 GB

10⁶ × 2 KB = 2 × 10⁹ bytes ≈ 2 GB, before Redis overhead (often 1.5-2× for small keys). It fits comfortably on one instance, so a single Redis with a replica is a reasonable answer.

3. CDNEasy

Users in Sydney say your image-heavy site is slow. Your servers are in Virginia. What does putting a CDN in front mainly help with?

  1. Serving static files from servers close to users
  2. Running database queries closer to the data
  3. Encrypting images and video at rest
  4. Replacing the load balancer at the origin
Show answer

Answer: A. Serving static files from servers close to users

Edge servers cache content near users, cutting latency and taking load off your origin. Mention it whenever a design serves large static assets globally.

4. Real-timeEasy

A chat app needs messages to appear instantly. Clients currently poll every 5 seconds. What's the better approach?

  1. Keep a WebSocket open so the server pushes messages
  2. Poll every 0.1 seconds instead of every 5
  3. Send each message as a push notification
  4. Upgrade to bigger database servers
Show answer

Answer: A. Keep a WebSocket open so the server pushes messages

Polling is slow to show updates and wastes requests when nothing changed. A WebSocket keeps a connection open both ways. Mention that you'd need to track which server holds each user's connection (for example with pub/sub).

5. ScalingEasy

Your only database box is maxed out. Your lead says "we'll scale horizontally, not vertically." What's the difference?

  1. Vertical: a bigger machine; horizontal: more machines
  2. Vertical: more machines. Horizontal: a bigger machine
  3. Vertical scales reads, horizontal scales writes
  4. No difference; both just mean adding capacity
Show answer

Answer: A. Vertical: a bigger machine; horizontal: more machines

Vertical scaling is simple but hits a ceiling and leaves one point of failure. Horizontal scaling grows further and survives failures, but requires statelessness, load balancing, and often data partitioning.

6. ArchitectureEasy

Myth or fact: splitting a monolith into microservices makes the system faster.

  1. Myth
  2. Fact
Show answer

Answer: A. Myth

Myth. In-process calls become network calls, which add latency and new failure modes. Microservices help teams deploy and scale parts independently; they're an organizational tool more than a speed boost.

7. ScalingEasy

Why do designs keep application servers stateless, storing sessions in a shared store instead?

  1. Any server can handle any request, so scaling out is easy
  2. Stateless servers use less CPU per request
  3. So the app can run without a database
  4. Because HTTP forbids servers from keeping state
Show answer

Answer: A. Any server can handle any request, so scaling out is easy

If session data lives on one server, users must be pinned to it (sticky sessions), and they lose state when it dies. Externalizing state to Redis or the database makes servers interchangeable.

8. CachingEasy

A product page gets 50k reads/second. The database CPU sits at 90%, and product data changes about once an hour. What do you add first?

  1. A cache in front of the database
  2. A message queue
  3. More columns in the products table
  4. A second application server
Show answer

Answer: A. A cache in front of the database

Read-heavy and rarely changing data is the textbook case for caching. Even a short expiry (say 5 minutes) absorbs almost all reads. Mention how you'd invalidate when a product changes.

9. Back-of-envelopeEasy

One app server handles about 1,000 requests a second. Peak traffic is 30,000 a second, and you want 2× headroom. How many servers?

  1. 15
  2. 30
  3. 60
  4. 300
Show answer

Answer: C. 60

30,000 ÷ 1,000 = 30 servers at peak, × 2 for headroom = 60. Headroom covers failures, deploys and traffic spikes. Spread them across availability zones.

10. Back-of-envelopeEasy

10 million daily active users each make 10 requests a day. Roughly what is the average load in requests per second?

  1. ~120
  2. ~1,200
  3. ~12,000
  4. ~120,000
Show answer

Answer: B. ~1,200

100 million requests ÷ 86,400 seconds ≈ 1,160/s. Round a day to 100k seconds for quick math. Then say peak is usually 2-3× average, so plan for about 3,000/s.

11. Rate limitingMedium

You need an API rate limit of 100 requests a minute per user, but short bursts should be allowed. Which algorithm fits?

  1. Token bucket
  2. Fixed window counter
  3. Round-robin
  4. Consistent hashing
Show answer

Answer: A. Token bucket

Tokens refill at a steady rate up to a maximum (the burst size); each request spends one. It needs only two numbers per user (tokens, last refill time), which fit easily in Redis.

12. QueuesMedium

Your message queue guarantees at-least-once delivery. What does that require from consumers?

  1. They must be idempotent: a message can arrive more than once
  2. Nothing; at-least-once means exactly once
  3. They must process messages in under 1 second
  4. They must never crash while processing a message
Show answer

Answer: A. They must be idempotent: a message can arrive more than once

If a consumer crashes after doing the work but before acknowledging, the message is delivered again. Dedupe with a message ID, or make the operation naturally idempotent ("set status = shipped" rather than "add 1").

13. Back-of-envelopeMedium

1 million new posts a day, about 1 KB each. Roughly how much storage over 5 years (before replication)?

  1. ~180 GB
  2. ~1.8 TB
  3. ~18 TB
  4. ~180 TB
Show answer

Answer: B. ~1.8 TB

1M × 1 KB = 1 GB a day. × 365 ≈ 365 GB a year, × 5 ≈ 1.8 TB. Then say it out loud: with 3× replication that's about 5.5 TB, small enough for a few machines.

14. DatabasesMedium

Myth or fact: some NoSQL databases support ACID transactions across multiple documents or items.

  1. Myth
  2. Fact
Show answer

Answer: B. Fact

Fact. Several document and key-value stores offer multi-item ACID transactions, and nearly all offer atomic single-item updates. Choose a database by data shape and access patterns, not by the SQL/NoSQL label.

15. ID generationMedium

A URL shortener runs on many servers. How do you generate short codes without collisions or a central bottleneck?

  1. Each server reserves ID blocks from a counter, then base62-encodes them
  2. Hash the long URL with MD5 and keep the first 7 characters, without checks
  3. Pick 7 random characters and hope
  4. Use the current timestamp in seconds, base62-encoded
Show answer

Answer: A. Each server reserves ID blocks from a counter, then base62-encodes them

Reserving ranges (say 1,000 IDs at a time) means one counter call per thousand codes. Base62 (a-z, A-Z, 0-9) fits 3.5 trillion IDs in 7 characters.

Practise like this every day

InterviewGrind gives you ten questions like these each day on your iPhone, with Pro tracks for company-style loops.

Get the launch email

More interview questions

Python · JavaScript · Java · C++ · SQL · Big-O · Coding patterns · CS fundamentals