140 System Design interview questions with detailed answers, sorted from basic to advanced. Free to practice, with progress saved automatically.
System design is the practice of sketching how a distributed system meets requirements for load, reliability and maintainability, usually probed through open-ended prompts. Topics include interview scenarios such as a real-time chat service, CAP theorem, monolith versus microservices, SQL versus NoSQL, sharding, consistent hashing, hot partitions, timeouts and resilience, observability, and payment flows.
and 68 more topics.
Frontend caching operates at multiple layers, each serving a different purpose: - Browser (HTTP cache): headers like Cache-Control and ETag cache static assets (JS, CSS, images), reducing network requests on return visits. - Application: React Query or SWR with a stale-while-revalidate strategy caches API data:…
The CAP Theorem states that a distributed system can only guarantee at most two of three properties simultaneously: - Consistency: every node returns the most recent data. - Availability: every request receives a response. - Partition Tolerance: the system keeps operating despite network partitions. In…
ACID puts data correctness right after every transaction first; BASE accepts that nodes are briefly out of sync so the system always answers and scales easily. ACID BASE --------- Stands for Atomicity, Consistency, Isolation, Durability Basically Available, Soft state, Eventually consistent After a write Reads…
Vertical Scaling (scale up) means upgrading the hardware of a single server — more CPU, RAM, or storage. Simple and requires no code changes, but limited by hardware maximums and creates a single point of failure. Horizontal Scaling (scale out) means adding more servers and…
A load balancer sits between clients and a group of servers. It receives requests and spreads them across the servers so no machine is overloaded, and it runs regular health checks so it stops sending requests to a failing machine. Common algorithms: Algorithm How it…
A CDN (Content Delivery Network) is a network of servers placed around the world (called edges) that keep copies of static files such as images, JS, CSS and video. Users download files from the edge nearest to them instead of from the distant origin server.…
A forward proxy sits in front of clients and sends requests outward on their behalf — the client knows about the proxy, while the external server has no idea where the request really came from. Used to bypass geo-restrictions, hide client IPs, filter content on…
Latency is the time to complete a single request (measured in ms) — lower is better. Throughput is the number of requests the system handles per unit of time — higher is better. The trade-off arises when: - Batching: grouping many requests and processing them…
A distributed system stores each piece of data on several replicas (copies). A consistency model is a promise about what a read may see after someone writes: the latest value, or possibly an old one that has not synced yet. Example: you change your avatar…
Sharding splits one database into several pieces (shards), each on its own server and holding part of the data, so you can scale horizontally when one server can no longer hold the data or handle the write load. The most important decision is the shard…
A read replica is a copy of the main database (the primary). The primary takes every write and ships the changes to the replica; the replica only serves read queries. Apps usually read more than they write, so moving reads to replicas takes load off…
Rate limiting caps how many requests a client (by IP, user or API key) may send in a period of time, to stop abuse and keep the backend from being overloaded. Over the limit, the server returns 429 Too Many Requests with a Retry-After header.…
CQRS (Command Query Responsibility Segregation) separates the write side (commands: create, update, delete, with business rule checks) from the read side (queries: return data only), each with its own model. placeOrder checks the rules, stores the order and emits an event. The handler prebuilds a…
Event Sourcing stores every change as a sequence of immutable events instead of only the current state. The state is the result of replaying the events from the start. Think of a bank statement: the balance is computed from transactions, not a number that gets…
When you scale horizontally (several servers behind a load balancer), a user's next request may land on a different server. If the session lives in the old server's RAM, the new server does not know who the user is. Three directions: pin the user to…
A Monolith deploys the whole application as one unit: modules call each other with in-process function calls and share one database. Microservices split the application into many small services, each deployed separately with its own database, talking over the network (HTTP, gRPC, message queues). Monolith…
An API Gateway is the single entry point for every client request to the microservices: a reverse proxy that picks the target service by path and forwards the request, plus the shared work every service needs. The client knows one address; splitting or changing services…
A Service Mesh is the infrastructure layer handling service-to-service communication in a microservice architecture, usually implemented as a sidecar proxy — every service pod gets a proxy container alongside it. What it gives you: mTLS to encrypt inter-service traffic, load balancing, circuit breaking, retries, timeouts,…
Circuit Breaker is a wrapper around calls to another service: when that service keeps failing, it stops calling for a while and fails immediately, like an electrical breaker tripping on overload. It stops cascading failure. Say Payment Service calls a slow Fraud Service: every request…
Saga solves this problem: one business operation touches several services, each with its own database, so there is no single transaction to roll everything back. A saga splits the operation into a chain of local transactions, each committing in one service's DB; when a step…
Event-Driven Architecture (EDA) is an architecture where services communicate through events, i.e. notices that "something happened" (OrderPlaced), instead of calling each other's APIs. A producer publishes events to a broker (Kafka, RabbitMQ) without knowing who receives them; consumers subscribe to the event types they need…
RabbitMQ is a queue-based message broker. The broker pushes messages to consumers, and once a consumer acks, the message is removed from the queue. Through exchanges it supports many routing styles (pub/sub, point-to-point, routing by key), which suits task queues and RPC. Kafka is a…
Serverless (usually FaaS, Function as a Service) is a model where you deploy individual functions and the cloud provider handles the servers: it creates instances when requests arrive, adds more under load, scales to zero when idle, and bills per invocation plus execution time. Examples:…
SQL (Relational DB): use when ACID transactions are required (finance, order management), data has a clear and stable structure, or complex JOINs are needed. PostgreSQL and MySQL are good defaults for most applications. NoSQL types: - Document DB (MongoDB, Firestore): flexible schema, each document can…
An index is a data structure (usually a B-Tree) that lets the database find records quickly without a full table scan – reducing query time from O(n) to O(log n). - B-Tree Index: the most common type; works for equality and range comparisons (=, <,…
Normalization means splitting data into tables so that each fact lives in one place, with tables linked by foreign keys. The normal forms 1NF, 2NF, 3NF and BCNF are the rules for getting there. Denormalization means deliberately storing the same fact in several places to…
Blob storage (object storage, such as AWS S3 or Google Cloud Storage) stores binary files like images, video and PDFs as key → file pairs. The standard approach: the file lives in blob storage, and the database stores only metadata (key, size, file type, owner).…
Problem with hash(key) % N: when node count N changes (add/remove one server), almost all keys move to different nodes → mass cache misses and a huge amount of data to move. Consistent Hashing: place both nodes and keys on the same hash ring (0…
Problem: a network timeout leaves the client unsure if the request succeeded → it retries → double charge / double order. POST is not naturally idempotent. Idempotency key: client generates a unique key (UUID) per business intent and sends it via Idempotency-Key header. Server: 1.…
Observability = inferring a system's internal state from external outputs. The three pillars complement each other: - Metrics — aggregated numbers over time (req/s, p99 latency, error rate, CPU). Cheap, long retention, for dashboards + alerting. Answers "is anything abnormal?". - Logs — discrete timestamped…
A webhook is a server-initiated HTTP callback to a customer's endpoint on an event (the inverse of polling). Reliable delivery: - Events go to a queue (Kafka/SQS); a worker reads and POSTs to the customer URL → decouples event creation from delivery (which can be…
The goal is not an exact number but to pick the right-sized architecture (need sharding yet? how much cache? a few servers or thousands?). Interviewers grade your reasoning, not decimals. Process: 1. Start from DAU and behavior: e.g. 100M DAU, each does 10 reads +…
When the cache runs out of memory, it must drop entries to admit new ones — the eviction policy decides which to drop. - LRU (Least Recently Used): evicts the entry untouched for the longest time. Assumes "recently used will be used again" (temporal locality).…
returnUrl is where the browser lands; IPN is a server-to-server call from the gateway. Only the IPN may flip an order to paid. - returnUrl: the user is redirected back after paying. It may never happen (tab closed, network lost, wallet app not reopening the…
No single control is enough — layer several, each raising the bot's cost. Before the account is created: - Rate limit per IP and per subnet, e.g. 5 signups/IP/hour. Bots rotate proxies, so this is only the first layer. - Honeypot: a CSS-hidden input; humans…
IPNs go missing: your server was mid-deploy, the endpoint 500ed, a firewall blocked it, or the gateway had an incident. So the IPN cannot be your only mechanism — you need an active pull path too. Push + pull: 1. On order creation, store paymentstatus…
The key point: a refund is its own transaction, not an edit or deletion of the original one. The original payment record must stay intact for reconciliation and accounting. Data model: a refunds table referencing paymentid, with amount, reason, status (requested → processing → succeeded/failed),…
A presigned URL lets the client upload directly to S3 so your server never proxies bytes — but the server also loses the chance to inspect the payload inline. Compensate in two places: constrain the signature, and verify after the upload. Constrain at signing time…
Answer by scale — do not jump straight to Elasticsearch. Below a few million products, PostgreSQL covers all three requirements. Accent-insensitive search: use the unaccent extension to strip Vietnamese diacritics, and store the result in an indexed generated column rather than calling the function inside…
Separate the concepts: an audit log records human business actions (unlike application logs, which exist for debugging). It must be append-only — inserts only, no updates or deletes. Minimal table: Where to write it: inside the same transaction as the data change, so you never…
The rule: store UTC, convert at the edges. Use timestamptz in the database (Postgres normalizes to UTC), return ISO 8601 with an offset from the API (2026-08-06T14:30:00+07:00), and let the client render in the viewer's zone via Intl.DateTimeFormat. Using plain timestamp is the most common…
Two problems: too many writes and wrong counts. Too many writes: every view is an UPDATE against the same row. Concurrent requests queue on that row lock, and each update creates a new row version (in Postgres), bloating the table and its indexes. One viral…
Do not start drawing architecture. The commonly used flow has 6 steps, each with a time budget: 1. Clarify requirements (5-8 min) — lock the scope: who uses it, which features are in, which are out. Capture both functional and non-functional requirements. 2. Estimate (3-5…
Functional requirements answer "what can the system do": users post, follow others, read a feed. They become endpoints and tables. Non-functional requirements answer "how well must it run": target latency, availability, user scale, read/write ratio, acceptable consistency, cost, legal data-retention rules. Separating them matters because…
A prompt like "design Twitter" is deliberately vague — the interviewer wants to see whether you narrow the scope yourself. Questions worth asking: Scope - Which features are in scope for this session? (posting, feed, following — or also search, DMs, ads?) - Do we…
This set of numbers was popularized by Jeff Dean around 2010. Hardware today is faster on many lines, so use it to compare orders of magnitude, not for exact quotation. The table runs from fastest to slowest: Operation Time ------ L1 cache reference ~1 ns…
Estimate by orders of magnitude, round aggressively, and narrate each step. Step 1 — QPS. A day has ~86400 seconds, round to 100k seconds. Assume each user writes 2 posts/day: With a 100:1 read/write ratio, reads average ~20k QPS and peak ~50k QPS. That number…
Percentiles are the thresholds below which a given share of requests falls. p99 = 800 ms means 99% of requests are faster than 800 ms and 1% are slower. The average hides the tail. Take 1000 requests: 990 at 50 ms, 10 at 5000 ms.…
Three layered concepts: - SLI (Service Level Indicator) — the measured signal: success rate, p99 latency, write success ratio. It comes straight from the system. - SLO (Objective) — an internal target set on an SLI: "99.9% successful requests over 30 days", "p99 under 300…
The goal here is to lock the contract between client and system before discussing internals. Write 3-5 core endpoints, one line each, with parameters and return values: Points worth raising proactively: - Cursor pagination, not offset. Offset skews results when new rows are inserted and…
This step settles four things: core entities, storage type, keys (primary key and shard key), and indexes. 1. Entities and relations. List 3-5 core tables with the important columns, not every column. For a news feed: users, posts, follows, feeditems. 2. Pick storage by query…
A SPOF is a component whose failure stops the whole system or a core business flow. How to audit: walk each box in the diagram and ask "what if this dies right now". Commonly missed spots: - Database primary — read replicas alone still leave…
No timeout means accepting an unbounded wait. When a downstream service hangs, every waiting request still holds a thread, a connection, and a slot in the connection pool. Within tens of seconds the pool is exhausted and your service stops serving even requests unrelated to…
Answer in order of cheapest and fastest first — do not jump straight to a distributed setup: 1. Measure first: CPU, RAM, disk I/O, DB connections, p95 latency. Without knowing the bottleneck every change is a guess. 2. Fix the obvious: missing indexes, N+1 queries,…
A sticky session configures the load balancer to always route a given client to one specific backend, usually via an LB-issued cookie or a source-IP hash. Why avoid it: - Skewed load: one backend can attract the heavy clients and nothing rebalances it; the balancing…
The LB relies on health checks to decide which backends still receive traffic. - Passive: it watches real traffic — a backend that returns errors or times out beyond a threshold is marked bad and taken out temporarily (maxfails / failtimeout in nginx). - Active:…
This is replication lag: the write goes to the primary while the follow-up read lands on a replica that has not applied it yet. With asynchronous replication tens of milliseconds is normal, but a busy replica or a large write transaction pushes lag into seconds.…
Queue-based load leveling: instead of letting a spike hit the processing service directly, requests go into a queue and consumers drain it at a steady rate the system can sustain. The spike turns into latency rather than errors. It fits work that needs no immediate…
Pick the metric that matches the workload: - CPU-bound service → CPU utilization. - I/O-bound service (waiting on the DB or an external API) → CPU stays flat while you are already saturated; use in-flight request count or RPS per instance. - Queue workers →…
Because total database connections equal instance count × pool size per instance. A pool of 20 across 4 instances is 80 connections; across 40 instances it is 800, far beyond PostgreSQL's default maxconnections of 100. This is the classic horizontal-scaling trap: local config is unchanged,…
Ask for the read/write ratio before drawing any architecture, because the two optimize in opposite directions. Read-heavy (social feeds, news, marketplaces — reads often tens to hundreds of times writes): - Multi-layer caching, CDN for public content. - Read replicas to spread read load. -…
Clarify first: who creates links (internal marketing, not public), do links expire, must analytics be real-time or can they lag a few minutes. Assume 100k links and 5M clicks/month — roughly 2 clicks/sec on average, maybe 500/sec at campaign peak. At that size one Postgres…
Clarify scale: 5M products, a few thousand shops, reads outnumbering writes by hundreds to one. That is why you split the read path from the write path (light CQRS, no event sourcing needed). Source of truth is Postgres: Use a materialized path column for the…
Clarify first: a customer may only see the courier for their own order, updates every 3-5 seconds are enough (not 60/sec), and only while the delivery is active. Assume 20,000 active couriers pinging every 5 seconds → 4,000 writes/sec. That number drives the whole design:…
Three requirements drive the design: messages are not lost, ordering within a conversation is stable, and offline users receive everything when they reopen the app. Data model — getting the primary key right solves half the problem: seq is a per-conversation monotonic number assigned by…
The right answer at this scale is "do not rush into fan-out." With a few hundred thousand users each following a few hundred sources, building the feed on read (pull) is sufficient and has the fewest moving parts. Data model: Build on read: fetch the…
Business services must not know which channel is used. They emit a business-meaningful event; channel selection, templating, and rate limiting live in the notification system. Flow: Core data model: Channel selection: order by cost and reliability — push (near free) → email → SMS last…
State the first problem up front: UPDATE posts SET views = views + 1 for every view makes every request lock the same row and queue behind each other. A viral post becomes a hot row; other posts are unaffected. Approach: count in Redis, flush…
Opening principle: files must not pass through the API server. The client requests a pre-signed URL and uploads directly to object storage (S3/GCS/R2). The API only authorizes and records completion — so it never spends bandwidth or disk. Flow: Validation at step 1 is the…
Clarify: doctors have weekly recurring schedules, shifts split into 15-30 minute slots, occasional unplanned absences, and a high cancellation rate. Traffic is low (tens of req/s) but correctness requirements are high — this is a data-modelling and concurrency problem, not a scaling one. Data model…
Clarify scale: 5,000 employees, 2-4 punches a day → about 20,000 records/day concentrated in two short windows. Total load is tiny; the difficulty is correctness and business rules, not scale. Data model: Keep attendanceevents as append-only raw data — never edited, never deleted. timesheets is…
Two clarifying questions decide everything: must the cart survive closing the browser (yes), and can logged-out visitors add to cart (yes — forcing login first hurts conversion). Where it lives: do not keep the cart only in localStorage — that cannot sync across devices. Store…
Usually no. The common advice is monolith first: start with a well-modularized monolith and extract services only for a concrete reason. Why not yet: - Business boundaries are not stable early on. Cut in the wrong place and every change requires editing and deploying several…
Split by business capability / subdomain, not by technical layer. A bounded context is the scope in which one data model has a consistent meaning. Take the word "Order": - In the Sales context an Order has a cart, promotions, and totals. - In the…
Database per service: each service owns its schema; others reach it only through its API, never by reading or writing its tables. Why: - A shared database couples services to table structure. Renaming a column then needs a coordinated multi-team deploy — exactly what microservices…
Two essentials: a correlation id and centralised logs. Correlation id (request id): generate a unique id at the edge (gateway or first service), put it in a header, propagate it through every downstream call, and include it in every log line. So nobody has to…
Two main options: API composition or a CQRS read model. API composition — one component (gateway/BFF/aggregator) calls each service and merges the results. The order must be fetched first because userId lives inside it; then user, payment and shipping are called in parallel. - Pros:…
A trace is the full journey of one request through the system. A span is one unit of work inside it (an HTTP call, a DB query, a message handler) with a name, start/end time, attributes, and a parent span id. Linking spans by parent-child…
The problem: instances come and go constantly (autoscaling, deploys, containers dying and being recreated), so IPs and ports are not fixed. Addresses cannot be hardcoded in config. General mechanism: each instance registers with a service registry at startup and sends heartbeats; the registry evicts dead…
A three-tier architecture splits an application into three independently running tiers: the presentation tier displays data and takes user input, the application tier (business logic) processes it, and the data tier stores it. Each tier talks only to its neighbour: the UI never touches the…
Split it into two rhythms: the heavy part is computed offline in batches (every few hours), and the real-time part only lightly adjusts based on what just happened in the session. At serving time the API only reads precomputed results from Redis and re-ranks them;…
