System design interview questions

1.You are asked to design a system. What do you do before drawing any boxes?

What a strong answer shows

A strong answer separates functional requirements from non-functional ones such as latency, availability, consistency and scale. It agrees the scope out loud and states assumptions the interviewer can correct. The trap is jumping straight to components, then designing for a problem nobody asked about.

2.How would you estimate the traffic and storage a new service needs?

What a strong answer shows

Start from daily active users and actions per user, convert to average requests per second, then allow for a peak multiple. Multiply object size by write rate and retention to get storage, and note the read to write ratio. Weak answers chase precise arithmetic instead of using round numbers to decide which parts need to scale.

3.What is the difference between vertical and horizontal scaling?

What a strong answer shows

Vertical scaling gives one machine more CPU, memory or disk; horizontal scaling adds more machines behind a load balancer. A strong answer notes that vertical scaling is simpler but has a ceiling and a single point of failure. Horizontal scaling needs stateless services and a plan for shared data, which weak answers skip.

4.What does a load balancer do, and how does it decide where to send a request?

What a strong answer shows

It spreads traffic across healthy instances and removes failing ones using health checks. A strong answer names algorithms such as round robin, least connections and hashing, and explains layer 4 versus layer 7 balancing. The trap is forgetting that the load balancer itself must be redundant.

5.Why do we try to keep application servers stateless?

What a strong answer shows

If no request depends on memory held by one server, any instance can serve it, so you can add, remove or replace instances freely. Session data moves to a shared store, a signed token or the database. Weak answers reach for sticky sessions, which make scaling and deploys harder and lose state when an instance dies.

6.Where in a system can you add a cache, and what makes data worth caching?

What a strong answer shows

Caches can sit in the browser, a CDN, a reverse proxy, the application process or a shared store such as Redis. Good candidates are read often, change rarely and are expensive to compute or fetch. The trap is caching without saying how stale data may be or how entries are invalidated.

7.What does a CDN do, and what would you serve through one?

What a strong answer shows

A CDN caches content at edge locations close to users, cutting latency and load on the origin. It suits static assets, images, video and cacheable API responses, controlled by cache headers. A strong answer covers versioned file names or purges for updates, and warns against caching personalised responses by mistake.

8.How do you choose between a relational database and a NoSQL store?

What a strong answer shows

Relational databases give joins, transactions and a strict schema, which suit related data and integrity rules. Key-value, document and wide-column stores trade some of that for simple access patterns at large scale. Weak answers pick NoSQL because it scales, without naming the queries the system must answer.

9.How does an index make a query faster, and what does it cost?

What a strong answer shows

An index, usually a B-tree, lets the database find matching rows without scanning the whole table. The cost is extra storage and slower writes, because every insert and update must also change the index. A strong answer adds that column order matters in composite indexes and that unused indexes are pure overhead.

10.Design the REST API for a simple resource such as a list of orders.

{
  "data": [
    { "id": "ord_812", "status": "paid", "total": 4200 }
  ],
  "next_cursor": "eyJpZCI6Im9yZF84MTIifQ"
}

What a strong answer shows

Use nouns for resources, HTTP methods for actions and status codes that mean what they say. A strong answer covers pagination, filtering, validation errors with a clear body and a versioning plan. The trap is verbs in URLs and returning a 200 status with an error message inside.

11.How do you keep a cache consistent with the database?

What a strong answer shows

Describe cache-aside with a TTL, and deleting the key after a write rather than updating it, to avoid racing writers. A strong answer names the remaining race where a slow reader refills stale data, and the stampede when a hot key expires. It mentions fixes such as short TTLs, request coalescing and jittered expiry.

12.What changes in your application when you add read replicas?

What a strong answer shows

Reads scale out, but asynchronous replication means a replica can lag behind the primary. A strong answer handles read-your-writes, for example by routing a user's reads to the primary shortly after they write. The trap is assuming replicas help write throughput, which they do not.

13.How would you shard a large table, and how do you pick the partition key?

What a strong answer shows

Pick a key that spreads load evenly and keeps the most common queries on a single shard. A strong answer compares hash and range partitioning and explains the cost of cross-shard queries and resharding. Weak answers choose something like creation date, which sends every new write to one shard.

14.Explain the CAP theorem. Is PACELC more useful in practice?

What a strong answer shows

During a network partition a system must choose between consistency and availability. PACELC adds that, even without a partition, it trades latency against consistency, which is the choice teams make every day. The trap is saying a system picks two of three, as if partitions were optional.

15.When would you put a message queue between two services?

What a strong answer shows

Use a queue when work can happen later, when the producer must not wait for a slow consumer, or to absorb bursts. A strong answer covers at-least-once delivery, retries with backoff, dead-letter queues and monitoring queue depth. Weak answers ignore that consumers then see duplicates and sometimes out-of-order messages.

16.A client retries a payment request after a timeout. How do you avoid charging twice?

What a strong answer shows

The client sends an idempotency key, and the server stores the key with the result in the same transaction as the charge. A repeat request with that key returns the stored result instead of doing the work again. A strong answer adds retries with exponential backoff and jitter, and only on errors that are safe to retry.

17.Design a rate limiter for a public API.

What a strong answer shows

Compare token bucket, fixed window and sliding window, and say which bursts each one allows. For many servers, keep counters in a shared store such as Redis and update them atomically. A strong answer returns a 429 status with a retry hint and decides what happens when the limiter's store is down.

18.Design a URL shortener.

What a strong answer shows

Cover ID generation with a counter or range allocation encoded in base62, or hashing with collision checks. Reads far outnumber writes, so a key-value store plus a cache and CDN fits well. A strong answer discusses permanent versus temporary redirects, expiry, abuse checks and click analytics written asynchronously.

19.Offset or cursor pagination: which would you use for a large, changing list?

What a strong answer shows

Offset pagination is simple but gets slower as the offset grows and skips or repeats rows when data changes between pages. Cursor pagination continues from the last seen sort key, so it stays fast and stable. A strong answer notes that cursors need a unique, indexed sort order and cannot jump to an arbitrary page.

20.What problem does consistent hashing solve?

What a strong answer shows

With plain modulo hashing, adding or removing a node remaps almost every key. Consistent hashing places nodes and keys on a ring, so only keys near the changed node move. A strong answer mentions virtual nodes to even out load, and where it is used, such as caches and partitioned stores.

21.How would you know your service is healthy in production?

What a strong answer shows

Define SLIs such as latency, error rate and availability, set SLOs on them and alert on symptoms users feel. Combine metrics, structured logs and distributed traces linked by a request ID. Weak answers list tools, or alert on CPU usage, instead of saying what is measured and who gets paged.

22.Design a system that sends push, email and SMS notifications.

What a strong answer shows

Accept requests through an API, check user preferences, then place messages on per-channel queues with workers calling each provider. A strong answer covers retries, deduplication, rate limits per user, templates and delivery tracking. The trap is calling providers synchronously in the request, so one slow provider blocks everything.

23.Design the home feed for a social network.

What a strong answer shows

Compare fan-out on write, which pushes posts into followers' feeds, with fan-out on read, which assembles feeds on request. A strong answer uses a hybrid, pulling posts from accounts with huge followings at read time. It also covers ranking, feed caches, pagination and what happens when a post is deleted.

24.Design a one-to-one and group chat service.

What a strong answer shows

Use persistent connections such as WebSockets, with a routing layer that knows which server holds each user's connection. A strong answer covers message ordering per conversation, delivery and read receipts, offline delivery and presence. It also explains storage keyed by conversation and how group size changes the fan-out.

25.How do you update a database and publish an event without losing one or the other?

What a strong answer shows

Writing to the database and then the broker can fail between the two steps. The outbox pattern writes the event to a table in the same transaction, and a relay or change data capture publishes it. A strong answer accepts at-least-once delivery and makes consumers idempotent, rather than promising exactly-once.

26.A downstream dependency becomes slow. How do you stop it taking your service down?

What a strong answer shows

Set timeouts on every call, cap retries and use circuit breakers so failing calls stop quickly. Bulkheads isolate thread or connection pools, and load shedding protects the service under overload. A strong answer defines a fallback, such as cached or partial data, and says which features may degrade.

27.One key receives a large share of the traffic. How do you handle it?

What a strong answer shows

Detect hot keys through metrics first, then decide whether the load is reads or writes. Reads can use local caches or replicated copies; writes can be split across sub-keys and merged later. Weak answers just add shards, which does not help when all the traffic hits one key.

28.How would you design a service to survive the loss of a whole region?

What a strong answer shows

Start from the recovery time and recovery point objectives, because they decide between active-passive and active-active. A strong answer covers data replication across regions, DNS or global load balancer failover and regular failover drills. With active-active writes, it explains how conflicts are resolved or how writes are routed to a home region.

29.An order touches payment, stock and shipping services. How do you keep them consistent?

What a strong answer shows

Avoid two-phase commit across services and use a saga, a sequence of local transactions with compensating actions on failure. A strong answer compares orchestration with choreography and makes every step idempotent. It admits the system is eventually consistent and designs for visible intermediate states, such as a pending order.

30.How do you change a database schema on a busy table without downtime?

What a strong answer shows

Use expand and contract: add the new column or table, write to both, backfill in batches, switch reads, then remove the old one. Each step must work with both the old and new application versions during a rolling deploy. The trap is a single migration that locks the table or breaks instances still running the old code.