System Design Interview: Q&A

A stateless tier lets any server handle any request, so you can autoscale and replace servers freely. Session state moves to a shared store (Redis, a NoSQL database), and the load balancer no longer needs sticky sessions.

Vertical scaling (a bigger machine) is simple but has a hard ceiling and leaves a single point of failure. Horizontal scaling (more machines) has no fixed ceiling and adds redundancy, but it needs load balancing, data partitioning, and handling of consistency.

Primary/replica replication gives read scaling and failover. The pitfalls are replication lag (stale reads), promoting a replica that is behind, and split-brain when two nodes both think they are primary.

Add a cache when the workload is read-heavy and some staleness is acceptable. Choose an expiration policy and an eviction policy (LRU/LFU). Watch for consistency between the cache and the database, a single point of failure, and a thundering herd on cold start or when a hot key expires.

A queue decouples producers from consumers, absorbs traffic spikes, and lets each side scale and fail independently.

DAU = 150M. Write QPS ≈ 150M × 2 / 86,400 ≈ 3,500. Peak ≈ 2× ≈ 7,000. Media storage ≈ 150M × 2 × 10% × 1 MB ≈ 30 TB/day, or about 55 PB over 5 years.

99.9% allows about 8.77 hours per year. 99.99% allows about 52.6 minutes. 99.999% allows about 5.26 minutes. Every added nine costs a lot more redundancy and automation.

• L1 cache ≈ 0.5 ns · main memory ≈ 100 ns
• Compress 1 KB ≈ 10 µs · round trip in one data center ≈ 500 µs
• Disk seek ≈ 10 ms · round trip from CA to Netherlands ≈ 150 ms

The lessons: memory is fast and disk is slow, avoid disk seeks, compress before sending, and cross-region calls are expensive.

Break the pipeline into stages (BGP → FPM → Redis → orchagent → syncd → SAI). Estimate the per-route cost of each stage, or its batch throughput. The slowest stage sets the total time. If SAI can take about 50k routes/s, 1M routes need at least 20 s. Then check whether the other stages keep up and whether they overlap.

Features in scope, number of users (DAU), read/write ratio, latency and consistency needs, data size and growth, existing tech constraints, and non-functional requirements (availability, security, cost). Write your assumptions down.

Jumping into a solution without clarifying the problem. Over-engineering. Going deep on one component too early. Ignoring trade-offs. Designing silently without talking to the interviewer.

Bottlenecks, failure scenarios, how to handle the next 10× of scale, monitoring and alerting, the rollout and upgrade strategy, and anything you would redesign given more time.

• Token bucket: tokens refill at rate r up to capacity b. Allows bursts. Simple and memory-efficient.
• Leaking bucket: a FIFO queue drained at a fixed rate. Produces smooth output, but bursts fill the queue.
• Fixed window counter: simple, but allows up to 2× the limit around window edges.
• Sliding window log: exact, but stores a timestamp for every request.
• Sliding window counter: weighted mix of the current and previous windows. A good approximation at low cost.

Client-side limits are unreliable. Server-side limits work, and so does middleware such as an API gateway. Put the limiter as close to the protected resource as the architecture allows, and as early as possible so that rejected work costs little.

Keep the counters in a central store such as Redis, and use atomic operations (a Lua script or INCR + EXPIRE) to avoid race conditions. For multiple data centers, use eventual sync or local limits with a global budget. Return HTTP 429 with X-Ratelimit-Remaining, -Limit and -Retry-After headers.

A hard limit never exceeds the threshold. A soft limit may exceed it briefly. Rejected requests can be dropped, or queued for later processing, for example orders that should not be lost.

When N changes, almost every key maps to a different server. That causes a storm of cache misses or data migration. Consistent hashing moves only about K/N keys.

Servers and keys are hashed onto a ring. Each key goes to the first server clockwise from it. With only a few real servers the partitions are uneven, so each server is placed at many points (virtual nodes). This evens out the load and also allows weighting servers by capacity.

Network ECMP. A switch hashes each flow's 5-tuple to pick a next hop. With naive modulo hashing, losing one next hop reshuffles most flows and breaks TCP connections through stateful devices.

When there is a network partition, a system must choose either Consistency (reject or block writes) or Availability (accept writes that may conflict). CP systems include a bank ledger or HBase. AP systems include Dynamo and Cassandra, which suit shopping carts. When there is no partition, the trade-off is latency vs consistency (PACELC).

N is the number of replicas, W the write acks required, and R the read responses required. If W + R > N, a read overlaps the latest write, which gives strong consistency. W=1, R=N gives fast writes. W=N, R=1 gives fast reads. N=3, W=R=2 is the classic balance.

With vector clocks ([server, version] pairs). If neither clock is an ancestor of the other, the writes conflict, and the client or the application reconciles them. The simpler alternative is last-write-wins, which can lose data.

• Detection: the gossip protocol (heartbeat counters).
• Temporary failures: a sloppy quorum plus hinted handoff.
• Permanent failures: anti-entropy with Merkle trees to find the replicas that differ.
• Data-center outages: replicate across data centers.

Write: append to the commit log, write to the memtable, and flush to an SSTable when the memtable is full. Read: check the memtable, then consult Bloom filters to skip SSTables that cannot contain the key, then read the SSTable. Background compaction merges SSTables.

• Multi-master (increment by k): hard to add servers, and IDs are not time-ordered across servers.
• UUID: no coordination, but 128 bits, not numeric, and not sortable.
• Ticket server: simple numeric IDs, but a single point of failure.
• Snowflake: 64 bits, time-sortable, no coordination at runtime.

1 sign bit · 41 bits of millisecond timestamp since a custom epoch (about 69 years) · 5 bits data center · 5 bits machine · 12 bits sequence (4,096 IDs per ms per machine). Watch out for clock skew (use NTP, and refuse to issue IDs if the clock moves backwards).

When the underlying system reassigns IDs, for example after a restart, other components that store the old IDs would break.

A 301 (permanent) is cached by browsers, which reduces server load. A 302 (temporary) sends every click to your server, which enables click analytics.

With base 62, 62⁷ ≈ 3.5 trillion codes. That covers 365 billion URLs (100M per day for 10 years), so 7 characters is enough.

Hashing (a CRC/MD5 prefix) needs collision checks, which a Bloom filter can speed up. Base-62 of a unique ID (from a Snowflake-style generator) never collides and is simple, but its codes are predictable and it needs an ID service.

Cache short → long mappings, since reads far outnumber writes. Keep the web servers stateless behind a load balancer, add database read replicas, and rate-limit abusive clients.

It holds the URLs still to be downloaded and enforces two things. Priority: front queues ordered by page importance. Politeness: back queues, one per host, each drained by a single worker with delays, so no site is hammered. Most of the frontier lives on disk, with in-memory buffers.

Keep a "URL seen?" check (a Bloom filter or hash set), and hash page content (a checksum or simhash) to detect duplicate or near-duplicate pages. Also guard against spider traps with a maximum URL length and depth.

Use consistent hashing to spread load across downloaders, save crawl state for recovery, and handle exceptions gracefully. Content processing uses a plug-in module chain, so a new content type (images, PDFs) is just another module.

Services call a notification API, which authenticates, rate-limits and validates the request. Notifications are fetched and rendered from templates and user settings, then placed on one queue per channel (iOS, Android, SMS, email). Workers call the third-party providers. Keeping a queue per channel means an outage at one provider does not block the others.

Persist a notification log and retry with backoff. Delivery is at-least-once, so deduplicate on the consumer side using an event ID. True exactly-once delivery is not achievable.

On write (push): the feed is precomputed, so reads are fast. But it is wasteful for inactive users and very expensive for celebrities with millions of followers. On read (pull): no wasted work, but reads are slow. Hybrid: push for most users, and pull celebrity posts at read time.

A news-feed cache holding only post IDs, a content cache for hot posts, social-graph caches, action caches (likes) and counters. Store IDs in the feed and hydrate them on read.

Polling is simple but wasteful. Long polling still needs reconnections and makes it hard to detect disconnects. WebSocket gives a bidirectional, persistent connection and is the usual choice. Plain HTTP is fine for non-real-time APIs such as login and profile.

A wide-column key-value store (HBase, Cassandra) handles very high write volume and range reads of recent messages. Order messages by an ID that is unique and sortable within the channel, either from a Snowflake-style generator or a local sequence.

Clients send periodic heartbeats. If no heartbeat arrives within a timeout, the user is marked offline, which avoids flapping on short disconnects. Status changes are fanned out to friends through pub/sub channels.

Limit the prefix length, and cache the top-k queries at every node. A lookup then takes O(1) time after walking the prefix. This trades memory for latency.

Usually not. Aggregate the query logs offline (for example weekly), rebuild the trie with workers, and swap it in. Serve it from a trie cache backed by a key-value store. Filter harmful suggestions at the serving layer.

Shard by prefix. Because letters are unevenly distributed, use a shard-map manager that splits or merges ranges according to historical load, rather than a naive a–m / n–z split.

The client gets a pre-signed URL and uploads directly to blob storage. Transcoding servers run a DAG of tasks (inspect, encode to several resolutions and codecs, thumbnails, watermark). The outputs go to storage and the CDN. The metadata is updated, and a completion event notifies the client. Metadata updates can run in parallel with the upload.

Split uploads into GOP-aligned chunks and make them resumable. Place upload centers close to users, and use message queues between stages so they are loosely coupled and can run in parallel.

Serve only popular videos from the CDN, and serve the long tail from your own servers. Encode unpopular videos on demand, and keep region-specific content in that region.

Delta sync then uploads only changed blocks. Blocks can be compressed and encrypted, and identical blocks are deduplicated by their hash. This saves a lot of bandwidth and storage.

The first version to be processed wins. The later one is kept as a conflicting copy for the user to merge. Metadata must be strongly consistent, so it goes in a relational database with ACID transactions.

A notification service using long polling. When a client is told something changed, it pulls the new metadata and blocks.

Geohash encodes lat/long into a base-32 string. A shared prefix means the points are close, and it is easy to store in any key-value store or database index. Edge cases: points near a cell border can have different prefixes, so also search the 8 neighbouring cells. Quadtree is an in-memory tree that subdivides until each leaf has at most K businesses. It adapts to density but must be rebuilt or updated, which makes it harder to operate. S2 maps the sphere onto a Hilbert curve and supports arbitrary regions (geofences).

Business data changes rarely, so it is read-heavy. Use read replicas and a cache keyed by geohash, holding a list of business IDs, plus a business-info cache. Deploy in multiple regions to reduce latency.

The client sends its location over WebSocket every ~30 s. The server updates a location cache (with a TTL), appends to a history database, and publishes to the user's own Redis pub/sub channel. Friends' WebSocket handlers subscribe to that channel, compute the distance, and push updates to clients within range.

Shard the channels across a Redis cluster using consistent hashing, with service discovery (for example ZooKeeper or etcd) holding the hash ring. The work is CPU-bound, so size the cluster by CPU. When adding nodes, resubscribe carefully to avoid a storm of resubscriptions.

Precompute tiles at each zoom level and serve them as static images or vectors from a CDN. The client calculates which tile URLs it needs from its position and zoom level, and servers take no part in that.

Split the road graph into routing tiles at several levels of detail (local streets, arterials, highways). A* or Dijkstra runs over the tiles loaded on demand. ETAs combine the route with live and historical traffic, often through ML models.

Sequential disk I/O is fast, especially with the OS page cache and batching. Segment files are easy to retain and delete. Consumers track their own offsets, so re-reading is cheap and the broker stays simple.

A topic is split into partitions, and ordering is guaranteed only within a partition, so choose the key carefully. Within a consumer group, each partition is consumed by one consumer. Parallelism is therefore capped by the partition count, and a coordinator rebalances partitions when consumers join or leave.

acks=0 is fastest, and messages may be lost. acks=1 waits for the leader only. acks=all waits for every in-sync replica (ISR) and is the most durable. At-most-once: commit the offset before processing. At-least-once: commit after processing. Exactly-once: at-least-once plus idempotent processing or transactions.

Larger batches and fewer flushes give higher throughput but add latency and memory use. Small batches give low latency but more per-message overhead.

Pull (Prometheus): easy health detection because a failed scrape means the target is down, but it needs service discovery and has trouble with short-lived jobs and firewalls. Push (agents): works across firewalls and for short jobs, but it is harder to tell a dead host from a quiet one. Many systems use both.

The workload is write-heavy, with time-range and aggregation queries over labelled series. TSDBs optimize this with columnar compression (delta-of-delta, Gorilla). Keep storage under control with downsampling (raw data for 7 days, 1-minute data for 30 days, 1-hour data for a year) and cold storage.

Lambda runs a batch path and a streaming path in parallel, which means two codebases. Kappa uses only the streaming path and handles reprocessing by replaying the log. Kappa is simpler if the stream engine is reliable enough.

Event time is when the click actually happened. It is accurate, but events arrive late. A watermark extends a window to wait for stragglers: longer is more accurate but adds latency. Events that arrive after the watermark are corrected by end-of-day reconciliation.

Store the consumer offset together with the aggregation result, atomically or in a distributed transaction. Deduplicate events by ID. Use a batch reconciliation job as a final check.

Tumbling windows are fixed and do not overlap (clicks per minute). Sliding or hopping windows overlap (top ads in the last M minutes). Session windows are separated by gaps in activity.

There are three options. Pessimistic locking (SELECT … FOR UPDATE) is safe but has contention and deadlock risk. Optimistic locking uses a version column and retries on conflict, which is good when contention is low. Database constraints (CHECK total_reserved ≤ total_inventory) are simple but hard to apply across tables.

Generate an idempotency key (the reservation ID) when the booking page loads, and put a unique constraint on it. A duplicate submission fails the constraint and returns the original result.

Shard by hotel_id, cache inventory with the database as the source of truth, and split into microservices. When a transaction must span services, use a saga or 2PC, or keep those tables in one database.

The access pattern is per-user, mostly recent, with read/unread filtering. A wide-column store partitioned by user_id, with denormalized tables (for example read and unread as separate tables) to avoid costly filters. Attachments go in object storage.

Use either a general search cluster (Elasticsearch, updated asynchronously through Kafka) or a custom per-user index built into the storage engine (an LSM tree optimized for heavy writes). Search is per mailbox, which makes partitioning simple.

Use dedicated IPs, warm them up gradually, classify and throttle outbound mail, handle bounces and complaints quickly, and set up SPF, DKIM and DMARC.

They have very different profiles. Metadata is small, mutable and queried. Object data is large, immutable and read by ID. Separating them lets each scale and be optimized on its own terms, much like a UNIX inode vs its data blocks.

3× replication has 200% overhead and gives simple, fast reads. Erasure coding (for example 8+4) has 50% overhead and similar or better durability, but reads and repairs cost more CPU and network. Use replication for hot data and erasure coding for cold data.

Append objects into large read-write files. When a file is full, seal it as read-only. Keep an object-ID → (file, offset, size) mapping in a local database such as RocksDB or SQLite. Deletes only mark objects, and compaction reclaims the space later.

Store a checksum with each object or segment and verify it on read. For versioning, add a version ID (for example a TimeUUID) to the metadata, and make a delete write a delete marker.

A sorted set is a hash plus a skip list. ZINCRBY, ZREVRANGE for the top 10, and ZREVRANK for a user's rank all run in O(log n). Ranking with SQL means sorting large tables on every query, which does not work in real time.

Either use fixed partitions by score range, which makes the top-N query easy, or hash partitions, which need a scatter-gather to find the top N. Persist scores to a database as the source of truth, and rebuild Redis from it if needed.

Pass an idempotency key (for example the order ID) to your own API and to the PSP. Combine at-least-once retries with idempotent processing to get effectively exactly-once behaviour.

Persist the payment state machine. Retry transient errors with exponential backoff and jitter. Send messages that keep failing to a dead-letter queue. Never retry non-retryable errors, such as an invalid card.

Async systems drift, so a nightly job compares your ledger with the PSP and bank settlement files and flags mismatches. Double-entry means every transaction debits one account and credits another by the same amount, so all entries sum to zero. This makes errors detectable.

• 2PC: database-level prepare/commit. Strong consistency, but locks are held and the coordinator is a single point of failure.
• TC/C (Try-Confirm/Cancel): application-level with compensating actions. No long locks, but more code.
• Saga: a sequence of local transactions, each with a compensating transaction. Can be choreographed or orchestrated. Good for long-lived flows.

Store an immutable log of commands and events, and derive the state (balances) by replaying them. The result is fully auditable and reproducible. Combine it with CQRS: one write model, and many read models built from the event stream. Snapshots speed up replay.

Replicate it with a consensus protocol (Raft) across several nodes. This is state-machine replication: every node applies the same log in the same order and ends up in the same state.

The path is client gateway → risk checks → order manager → sequencer (stamps sequence IDs so there is a total order) → matching engine (price-time priority on the order book) → sequencer → market data and reporting.

Put everything on one server. Pin a single thread per component to a CPU core, with no context switches or locks. Communicate through shared memory (mmap) or ring buffers. Avoid garbage collection and disk on the critical path. Keep the design deterministic so that a hot-warm replica can take over by replaying the same event log.

No locks and no contention, predictable latency, and easy replication by replay.