Frequently asked system design interview questions on scaling, load balancing, caching, databases, replication, sharding, queues, consistency and classic designs, with hints and answers.
20 questions · Updated
Bigger, or more?
Vertical scaling uses a bigger machine, and it has a limit. Horizontal scaling adds more machines, which needs stateless servers, but it scales further and adds redundancy.
Spread and protect.
It spreads traffic across servers, removes unhealthy ones, and lets you add or replace servers without clients noticing.
Start from the access pattern.
Use relational databases when you need transactions, joins or flexible queries. Choose NoSQL for a specific pattern, such as very high write volume or simple key lookups.
Divide by seconds in a day.
200 million a day, divided by 86,400, is about 2,300 a second. Peak at three times that is about 7,000 a second.
Could any server handle the next request?
It keeps no user data between requests, so that any server can handle any request. This allows horizontal scaling and easy replacement. Sessions go in shared storage.
Who fills the cache?
The app checks the cache first. On a miss, it reads the database and stores the result. On a write, it updates the database, and deletes the cache entry.
What must you choose during a partition?
When a network partition happens, a distributed store must choose between consistency and availability. Since partitions cannot be avoided, that is the real choice.
Compare with hash modulo N.
With hash % N, changing N moves most keys. Consistent hashing places keys and servers on a ring, so that adding a server moves only a small share.
What does each replica do with a write?
Every replica must apply every write, so they add read capacity only. Write load needs sharding, batching or queues.
A popular key expires.
A popular entry expires, and many requests hit the database together. Use a lock so that one request refills it, or refresh entries before they expire.
A key sent by the client.
The client sends an idempotency key, and the server stores the result under that key. A retry with the same key returns the stored result.
The user need not wait.
Put the job on a queue, and return a job ID at once. A worker builds the report, and the client polls for it, or gets a notification.
Algorithm, storage, location.
Use a token bucket in Redis with atomic operations, at the API gateway, keyed by user or API key. Return 429 with Retry-After, and decide whether to fail open if Redis is down.
Read-heavy, with short codes.
Generate 7-character base62 codes from block-allocated IDs. Store code and URL in a database, and cache popular links in Redis. Redirect with 302 if you need analytics, and send click events to a queue.
Fan-out on write fails for celebrities.
Use a hybrid. Fan out on write for normal accounts, storing post IDs in a Redis feed for each follower. Merge posts from very large accounts at read time.
Do not trust device clocks.
Assign an increasing sequence number per conversation on the server. Devices sort by it, and they use gaps to detect missed messages.
Check and update in one step.
Use a conditional UPDATE or a row lock, so that the check and update are atomic, plus a unique constraint. Hold seats with an expiry during payment.
Compensating actions.
Use a saga: a chain of local transactions, with compensating actions on failure. Use the outbox pattern, so that events are published reliably.
Do not scan everyone.
Index locations by cell, using geohash, a quadtree or a hexagon grid, and search the rider's cell and its neighbours. Keep the latest positions in memory.
Follow the request.
Check recent deployments, then look at p99 latency, error rates and saturation. Use traces to find the slow service, and logs to find why. Check the database, the cache hit ratio, and queue length.