System Design interview questions and answers

Clarify requirements: functional features and non-functional needs (scale, latency, availability, consistency). Estimate load and storage. Define the API and data model. Draw the high-level design, then deep-dive into the hardest parts (storage, scaling, caching, failure). Discuss trade-offs, bottlenecks and how you would monitor it. Keep checking in with the interviewer.

When a network partition happens, a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a response). A bank ledger chooses consistency and may reject requests during a partition; a shopping cart or social feed chooses availability and reconciles later. Without partitions you can have both; PACELC adds the latency vs. consistency trade-off in normal operation.

Choose relational databases for structured data with relationships, transactions and flexible queries (orders, payments). Choose NoSQL for very high scale with simple access patterns, flexible schemas or specific models: key-value (sessions), document (catalogues), wide-column (time series, feeds), graph (social connections). Many systems use both.

First, indexes and query tuning, then a bigger machine. Add caching for hot reads, read replicas for read scaling, connection pooling, and partitioning large tables. When writes or data size exceed one machine, shard by a well-chosen key. Move analytics to a separate store, and archive cold data.

Generate short codes with a base62-encoded counter or random ID (checking collisions), store code-to-URL mappings in a key-value store, serve redirects (301 or 302) from a cache-heavy read path with a CDN, and record clicks asynchronously through a queue. Reads dominate, so cache aggressively and replicate the store.

Fan-out on write pushes new posts into followers' precomputed feeds (fast reads, costly for celebrities); fan-out on read builds feeds at request time (cheap writes, slow reads). Most systems mix them: push for normal users, pull for accounts with huge followings, with ranking and caching on top.

Clients hold WebSocket connections to gateway servers; a presence service tracks who is online and where. Messages are stored in a partitioned store (by conversation), delivered via pub/sub to the recipients' gateways, acknowledged, and queued for offline users with push notifications. Ordering is per conversation using sequence numbers.

Throughput is work per unit time; latency is time per request. Batching, queues and larger buffers raise throughput but add waiting time; very low latency often needs spare capacity, which lowers utilisation. Design to meet latency targets at the percentiles that matter (p95, p99) while keeping enough throughput.

Cache-aside (the app loads on a miss), read-through, write-through (write cache and database together), write-behind (write cache, flush later) and refresh-ahead. Caches live at many layers: browser, CDN, reverse proxy, application (Redis) and database. Invalidation, TTLs and stampede protection are the hard parts.

A load balancer spreads requests over healthy servers and removes failed ones using health checks. Layer 4 balancers route by IP and port; layer 7 by HTTP data such as path or headers. Algorithms include round robin, weighted round robin, least connections, least response time and IP or consistent hashing for stickiness.

Servers and keys are placed on a hash ring; each key belongs to the next server clockwise. Adding or removing a server moves only the keys next to it, roughly 1/N, instead of remapping nearly everything. Virtual nodes spread load evenly. It is used in distributed caches and databases such as Cassandra and DynamoDB.

To decouple services, absorb traffic spikes, run slow work asynchronously (emails, video processing), retry failures and fan out events to several consumers. Queues (SQS, RabbitMQ) deliver each message to one consumer; logs and streams (Kafka) keep an ordered history that many consumer groups read independently.

Remove single points of failure with redundancy across availability zones, health checks and automatic failover, replicated data, stateless services, timeouts, retries with backoff, circuit breakers, graceful degradation and load shedding. Measure with SLOs and test failure with chaos experiments.

Strong consistency means every read returns the most recent write, at the cost of coordination and latency. Eventual consistency means replicas converge if writes stop, so reads may briefly be stale but the system stays fast and available. Many systems mix them: strong for balances, eventual for likes and view counts.

Cache the hot data closer to clients, add random suffixes to spread writes across partitions and aggregate on read, replicate hot items, or use dedicated capacity. Detect hot keys with metrics before they cause overload.

Changes are appended to a durable log before being applied to the main data structures. After a crash, the system replays the log to recover. Databases, message brokers and consensus systems all rely on it for durability and replication.

Algorithms like Raft elect a leader by majority vote; the leader appends entries to its log and replicates them, committing once a majority acknowledges. If the leader fails, followers time out and elect a new one. Majorities ensure only one valid leader and no lost committed writes.

Use clear resource-oriented REST or GraphQL schemas, version them, paginate with cursors, support idempotency keys for writes, return consistent errors, rate-limit per client, and document with OpenAPI. Keep internal service APIs separate from public ones.

A way for a slow consumer to signal producers to slow down, using bounded queues, flow control or rejecting work, instead of buffering until memory runs out. It keeps overloaded systems stable and degrades gracefully.

Producers publish events to a queue; a notification service applies user preferences, rate limits and templates, then sends through channel workers (email, SMS, push) with retries and dead-letter queues. Track delivery status and deduplicate with idempotency keys.

Avoid them where possible. Use the saga pattern: a sequence of local transactions with compensating actions on failure, coordinated by events (choreography) or a central orchestrator. The outbox pattern ensures database changes and published events stay consistent.

Pick an algorithm (token bucket for bursts, sliding window for accuracy), key the limit by user or API key, keep counters in a shared store like Redis with atomic updates, return 429 with Retry-After, and decide whether to fail open or closed if the store is down. Enforce at the gateway.

An idempotent operation has the same effect whether it runs once or many times. Networks cause retries and duplicate messages, so payments, orders and consumers use idempotency keys or natural unique keys to ignore repeats.

A monolith is simpler to build, test and deploy, and is usually right for small teams and new products. Microservices let teams deploy and scale parts independently, but add network calls, distributed data, observability and operational cost. Many teams start with a modular monolith and split out services when there is a clear reason.

Write the business change and an event row to the same database in one transaction; a separate process reads the outbox table and publishes events to the broker. This avoids losing events or publishing events for rolled-back changes.

Emit structured logs with request IDs, metrics for rate, errors and duration (RED) per service, and distributed traces across services. Define SLOs and alert on symptoms users feel, not every internal fluctuation.

A compact probabilistic set that answers 'definitely not present' or 'maybe present'. Systems use them to skip unnecessary disk or network lookups, for example in databases and caches, accepting a small false-positive rate.

Upload directly to object storage with pre-signed URLs, store metadata in a database, process files asynchronously (thumbnails, transcoding) and serve them through a CDN with cache headers.

Start from users and actions: daily active users × requests per user ÷ 86,400 gives average QPS; multiply for peak. Storage = items per day × size × retention × replicas. Bandwidth = QPS × response size. Round numbers and state assumptions; the reasoning matters more than precision.

Running in several regions to cut latency and survive regional outages. It introduces replication lag, conflict resolution, data-residency rules and more complex failover, so decide what must be strongly consistent and what can be eventually consistent.

1. ASpeed and cost
2. BConsistency and availabilityCorrect answer
3. CSQL and NoSQL
4. DLatency and throughput

Why: Partition tolerance is required, so the trade-off is C vs. A.

1. ASchema flexibility
2. BEncryption
3. CWrite throughput
4. DRead throughput and availabilityCorrect answer

Why: Reads spread across replicas; writes still go to the primary.

1. AMessage queue
2. BDNS cache only
3. CCDN
4. DLoad balancerCorrect answer

Why: It distributes requests and routes around failed servers.

1. AAccounts with millions of followersCorrect answer
2. BUsers with no followers
3. CRead-heavy feeds
4. DStatic pages

Why: Each post must be copied to every follower feed.

1. AFTP
2. BSMTP
3. CPlain polling every minute
4. DWebSocketsCorrect answer

Why: A persistent two-way connection.

1. ARetries forever
2. BLocal transactions with compensating actionsCorrect answer
3. CTwo-phase commit only
4. DA global mutex

Why: Each step can be undone.

1. AReplaces databases
2. BRuns cron jobs
3. CStores user passwords
4. DCaches content at edge locations near usersCorrect answer

Why: Edge caching cuts latency and origin load.

1. ARead-repair
2. BWrite-behind
3. CCache-asideCorrect answer
4. DWrite-through

Why: The app reads the DB on a miss and fills the cache.

1. ACompress data
2. BEncrypt keys
3. CMinimise data movement when nodes changeCorrect answer
4. DSort keys

Why: Only about 1/N of keys move when a node is added.

1. AUI rendering
2. BRead-only analytics
3. CScaling writes and storage beyond one machineCorrect answer
4. DFaster DNS

Why: Each shard holds part of the data and its writes.

1. ANGINX
2. BSQS standard queue
3. CApache KafkaCorrect answer
4. DMemcached

Why: Kafka retains messages so consumers read at their own offsets.

1. AA client request
2. BAcknowledgement from a majorityCorrect answer
3. CAll nodes
4. DOnly the leader

Why: Majorities tolerate failures.

1. ANo false positives
2. BExact counts
3. COrdering
4. DNo false negativesCorrect answer

Why: It may say 'maybe' wrongly but never misses.

1. ASingleton
2. BAdapter
3. CObserver
4. DOutboxCorrect answer

Why: Events are written in the same transaction.

1. Ap99Correct answer
2. Bp50
3. CAverage
4. DMinimum

Why: Slow requests matter to users.

1. ACompressing data
2. BReplicating writes
3. CCaching reads
4. DSlowing producers when consumers can't keep upCorrect answer

Why: Bounded queues are one form.

1. AThrough every app server
2. BInside the database
3. CBy email
4. DDirectly with pre-signed URLsCorrect answer

Why: It offloads app servers.

1. ABalances load
2. BCaches responses
3. CEncrypts traffic
4. DStops calls to a failing service for a whileCorrect answer

Why: It fails fast instead of piling up timeouts, then tests recovery.

1. A500
2. B401
3. C404
4. D429Correct answer

Why: 429 Too Many Requests.

1. AEvery read is the latest write
2. BReplicas converge if no new writes arriveCorrect answer
3. CNo data is ever lost
4. DTransactions across services

Why: Reads may be stale for a while.

1. A864,000
2. B3,600
3. C8,640
4. D86,400Correct answer

Why: 24 × 60 × 60 = 86,400.

1. AOffset-based
2. BPage numbers
3. CRandom
4. DCursor-basedCorrect answer

Why: Offsets get slow and skip items.

1. ACompression
2. BEncryption
3. CCrash recoveryCorrect answer
4. DFaster reads only

Why: Replay restores state.

1. ARate, Errors, DurationCorrect answer
2. BReads, Edits, Deletes
3. CRequests, Events, Data
4. DRetry, Escalate, Drop

Why: Per-service health signals.

1. ADelete the key
2. BAdd random suffixes and aggregate on readCorrect answer
3. CUse a bigger single server
4. DDisable caching

Why: Sharding the key spreads load.

1. A301Correct answer
2. B302
3. C307
4. D404

Why: 302 and 307 are temporary.

1. AKey-value
2. BGraphCorrect answer
3. CTime-series
4. DObject storage

Why: Graph databases model and traverse relationships efficiently.

1. AOnly IP address
2. BURL path and headersCorrect answer
3. CMAC address
4. DDisk usage

Why: It understands HTTP.

1. AUTF-16
2. BBase62Correct answer
3. CBase2
4. DASCII

Why: Letters and digits only.

1. ANo backups
2. BConflict resolutionCorrect answer
3. CToo little latency
4. DFewer servers

Why: Concurrent writes can conflict.