System Design

System Design Interview Guide

Level

From first design round to senior and staff loops

Time

6–8 weeks at about 8 hours a week; 2–3 weeks to refresh if you design systems at work

Scope

50 concepts in 9 stages and 70 practice problems

Before you start

Comfortable with one programming language and basic data structures; no distributed systems experience needed

What you will be able to do

• Run a design interview from vague prompt to defended design in 45 minutes, using a fixed structure
• Estimate traffic, storage and bandwidth in a few minutes and let the numbers drive the design
• Choose between SQL and NoSQL stores, caches, queues and streams, and explain the trade-off each time
• Scale reads and writes with replication, sharding, caching and asynchronous processing
• Reason about consistency, failure and recovery, and design for the failure modes interviewers probe
• Model classes and state for low-level design rounds, and write clean, extensible code for them

What the system design round tests

A system design interview gives you an open-ended prompt, such as design a chat app or design a rate limiter, and about 45 minutes to turn it into a working architecture. There is no single correct answer. The interviewer is watching how you think: whether you ask the right questions, size the problem, choose sensible building blocks, explain trade-offs and adapt when they change a requirement. A design that is simple, correct and clearly reasoned beats a complex one full of buzzwords.

Most companies run two kinds of design round. High-level design (often just called system design) is about services, data stores, queues and how they scale. Low-level design (also called object-oriented design or machine coding) is about classes, interfaces and state inside one program, such as a parking lot or an elevator controller, and often ends with working code. This page covers both, with low-level design in the last stage.

What is expected at each level

The 45-minute framework

Use the same six steps for every problem. Say the step out loud as you start it, so the interviewer can follow and steer you. The minutes are a guide; move faster on simple parts and keep the most time for the deep dive.

1. Clarify requirementsabout 5 min

   What to do. Agree the core features (functional requirements) and the qualities the system needs (non-functional requirements): scale, latency, availability, consistency, durability, cost and any regulatory needs. Write them down as a short list.

   What to say. Which three features matter most? How many users, and how active? Is it read-heavy or write-heavy? Can a user see slightly stale data? What happens if we lose a message? Confirm what is out of scope so you do not run out of time.

2. Estimate the scaleabout 5 min

   What to do. Turn users into requests per second for reads and writes, storage per year, and bandwidth. Round aggressively; the goal is the order of magnitude, not precision.

   What to say. State each assumption, then the result, then what it means: at 5,000 writes a second one database can still cope, but 5 PB of media means object storage and a CDN.

3. Define the API and data modelabout 5 min

   What to do. List the main endpoints or messages with their inputs and outputs, and the core entities with their keys and relationships. Pick a primary store for each entity.

   What to say. Note pagination, idempotency keys for writes that must not repeat, and which field is the partition key if the data will be sharded.

4. Draw the high-level designabout 10 min

   What to do. Draw clients, the load balancer or gateway, services, data stores, caches, queues and any background workers. Walk through one read and one write end to end so the design is proven to work before you optimise it.

   What to say. Start simple. A working single-region design first, then scale it, is much stronger than starting with twenty boxes you cannot explain.

5. Deep dive on the hard partsabout 15 min

   What to do. Pick the two or three parts that make this problem hard, such as fan-out for a feed, matching for ride hailing or exactly-once effects for payments, and go deep: data layout, consistency, hot spots, failure handling and the alternatives you rejected.

   What to say. Name the trade-off every time: I choose X because it gives us Y, and it costs us Z, which is acceptable here because of requirement W.

6. Wrap upabout 5 min

   What to do. Summarise the design, list the main risks and bottlenecks, and say how you would monitor it and what you would build next with more time.

   What to say. Mention metrics and alerts, how the system degrades under overload, and one or two improvements, such as a second region or a better ranking model.

Numbers for back-of-the-envelope estimates

Memorise a handful of numbers and conversion tricks. They let you size a system in two minutes and spot designs that cannot work. All values below are rounded orders of magnitude for typical modern hardware; real systems vary.

Time and traffic

• A day has 86,400 seconds; round it to 100,000 for quick maths. So 1 million requests a day is about 10 a second, and 1 billion a day is about 10,000 a second.
• Peak traffic is usually 2 to 5 times the daily average. Design for the peak, not the average.
• Read-heavy products such as feeds, catalogues and link redirects often have 10 to 100 reads for every write.

Latency, roughly

The lessons: memory is about a thousand times faster than an SSD for random reads, a network hop inside a data centre is cheap compared with a hop across the world, and anything that must cross an ocean on every request needs caching or a closer region.

Availability

Components in series multiply: two services at 99.9% that both must work give about 99.8%. Redundant copies in parallel improve it: two independent copies at 99% give 99.99% if either can serve.

A worked example

A photo-sharing app has 50 million daily users. Each uploads 0.2 photos and views 50 a day. Uploads: 10 million a day, about 100 a second on average and 300 at peak. Views: 2.5 billion a day, about 25,000 a second, perhaps 75,000 at peak, so reads dominate by 250 to 1. At 2 MB per photo plus thumbnails, storage grows by about 20 TB a day, or roughly 7 PB a year. Conclusions: photos go in object storage behind a CDN, metadata reads need caching and replicas, and the upload path is small enough for a modest service.

Core concepts

Work through the stages in order. Core topics come up in almost every interview; recommended topics separate strong answers from average ones; optional topics matter for specialised roles.

1. Stage 1Foundations: what you are designing forBeginner · 5 topics
2. Stage 2Networking, traffic and APIsBeginner · 7 topics
3. Stage 3Data storageIntermediate · 9 topics
4. Stage 4CachingIntermediate · 4 topics
5. Stage 5Asynchronous processing and streamingIntermediate · 6 topics
6. Stage 6Consistency and coordinationAdvanced · 5 topics
7. Stage 7Reliability and operationsAdvanced · 5 topics
8. Stage 8Security and specialised topicsAdvanced · 5 topics
9. Stage 9Low-level designIntermediate · 4 topics

Stage 1 Foundations: what you are designing for

Beginner5 topics

Goal. Explain the qualities every system trades off, and size a problem before designing it.

Scalability: vertical and horizontal Core

Scalability is the ability to handle more load by adding resources. Vertical scaling gives one machine more CPU, memory or faster disks: simple, no code changes, but capped and expensive at the top, and still a single point of failure. Horizontal scaling adds more machines that share the work: nearly unlimited and resilient, but the software must be built for it.

The key enabler is statelessness. If a web server keeps no user data in memory between requests, any server can handle any request and you can add or remove servers freely. Push state into shared stores: sessions into a cache, files into object storage, data into databases. Scaling the stateful parts, the databases, is where most design interviews spend their time.

Practice. Walk through Scale a Web App from One Server to 10 Million Users and note which limit triggers each new component.

Latency, throughput and percentiles Core

Latency is how long one request takes; throughput is how many requests the system completes per second. They are related but different: batching raises throughput and often raises latency too. Always describe latency with percentiles. The average hides the slow requests users notice; p99 is the time under which 99% of requests finish.

Tail latency grows with fan-out. If a page calls 50 services in parallel and each has a 1% chance of being slow, about 40% of page loads hit at least one slow call. Techniques to cut tail latency include caching, timeouts with fast fallbacks, sending a duplicate request to a second replica after a short delay, and keeping slow work off the request path.

Practice. For any design you practise, write a latency budget: how many milliseconds each hop on the read path may take.

Availability, reliability and single points of failure Core

Availability is the share of time a system serves requests successfully, usually written in nines. Reliability is broader: doing the right thing correctly over time, including not losing or corrupting data. Durability is the specific promise that stored data survives failures.

A single point of failure is any component whose failure takes the system down: one database, one load balancer, one region, even one engineer who knows how to deploy. Remove them with redundancy (two or more copies), automatic failover and health checks. Redundancy has a cost, so match it to the requirement: an internal report can tolerate an hour of downtime, a payment API cannot.

Practice. Take any design from the list below and mark every single point of failure, then add the cheapest fix for each.

Back-of-the-envelope estimation Core

Estimates turn a vague prompt into constraints. Start from users and actions: daily active users times actions per user gives requests a day; divide by 100,000 for an average per second and multiply by two to five for the peak. Storage is objects per day times size times retention. Bandwidth is requests per second times response size.

Then read the results. Hundreds of writes a second fit one relational database; hundreds of thousands need partitioning. Terabytes fit a few machines; petabytes need object storage. If reads outnumber writes a hundred to one, caching and replicas will do most of the work. State assumptions clearly and round hard; interviewers care about the reasoning and the order of magnitude, not decimals.

Practice. Estimate requests, storage and bandwidth for Design YouTube before reading the walkthrough, then compare.

Functional and non-functional requirements Core

Functional requirements are what the system does: post a message, search products, book a seat. Keep the list to the three to five that define the product; everything else is out of scope unless the interviewer asks. Non-functional requirements are how well it must do them: scale, latency targets, availability, consistency, durability, security, cost and compliance.

Non-functional requirements drive the architecture far more than features do. A chat app that must deliver messages in order within a second, and never lose one, is a different system from one that may lose the odd typing indicator. Write both lists on the board and refer back to them when you justify each choice.

Practice. For Design a Chat App, write the functional and non-functional requirements and decide which ones change the design.

Stage 2 Networking, traffic and APIs

Beginner7 topics

Goal. Route traffic to healthy servers, expose clean APIs and choose the right real-time technique.

DNS and how a request reaches you Core

The Domain Name System turns names into addresses. A resolver walks from the root servers to the top-level domain to your authoritative servers, and every layer caches the answer for its time to live (TTL). Short TTLs let you move traffic quickly but add lookups; long TTLs are efficient but slow to change.

DNS is also a traffic tool: weighted records shift a share of users to a new deployment, geographic or latency-based records send users to the nearest region, and health-checked records remove a failed region. Know its limits: clients and resolvers may cache beyond the TTL, so DNS failover is measured in minutes, not seconds.

Practice. Explain step by step what happens between typing an address and the first byte arriving, including DNS, TCP, TLS and the load balancer.

Load balancers Core

A load balancer spreads requests across healthy servers and hides them behind one address. Layer 4 balancers forward TCP or UDP connections without reading them: fast and simple. Layer 7 balancers understand HTTP: they terminate TLS, route by path or host, add headers, retry and rate-limit.

Algorithms include round robin, least connections and consistent hashing when requests for the same key should reach the same server. Health checks remove failed servers; connection draining lets in-flight requests finish during deploys. The load balancer itself must be redundant, usually as a managed service or an active-passive pair sharing a floating address.

Practice. Study Design a Load Balancer and explain how it detects and removes a failed backend.

CDNs and edge caching Core

A content delivery network caches content at edge locations near users. Static assets, images and video segments are the classic use, and edge caching of API responses works for content that many users share. The result is lower latency, far less load on your servers and lower bandwidth cost.

Know cache-control headers, TTLs, cache keys (which parts of the URL and headers make a response unique), purging, and versioned file names so new releases bypass old caches. Lock the origin so only the CDN can reach it. For media-heavy systems, the CDN usually serves the large majority of bytes, which changes the cost picture entirely.

Practice. Read Design a Content Delivery Network and describe how a request is routed to the nearest edge.

Reverse proxies and API gateways Recommended

A reverse proxy sits in front of servers and acts on their behalf: terminating TLS, compressing, caching and routing. An API gateway is a reverse proxy specialised for APIs: one entry point that handles authentication, rate limiting, request validation, routing to many backend services, and sometimes combining responses.

A gateway keeps cross-cutting concerns out of each service, but it becomes critical infrastructure: it must scale horizontally, stay thin and avoid business logic. For mobile clients, a backend-for-frontend layer tailors responses to each client type so phones do not make ten calls to render one screen.

Practice. Design the gateway for Design an Internal LLM Gateway and list what belongs in it and what does not.

API styles: REST, RPC and GraphQL Core

REST models resources with URLs and HTTP methods; it is simple, cacheable and the default for public APIs. RPC frameworks such as gRPC call functions with typed messages over HTTP/2; they are compact and fast, and suit service-to-service calls. GraphQL lets clients ask for exactly the fields they need from one endpoint, which helps complex front ends but makes caching and rate limiting harder.

Whatever the style, design for change and safety: version the API, paginate lists with cursors rather than offsets, return consistent error formats, accept an idempotency key on writes that must not happen twice, and document limits. In interviews, write three to five endpoints with their key fields and move on.

Practice. Write the API for Design a URL Shortener, including error cases and how a client retries safely.

Real-time updates: polling, SSE and WebSockets Core

Clients get updates in four main ways. Short polling asks every few seconds: simple but wasteful. Long polling holds a request open until there is news. Server-sent events keep one HTTP response open and stream events from server to client. WebSockets keep a two-way connection for chat, games and collaboration.

Persistent connections change the architecture: each server holds many open connections, so you need a way to find which server holds a user's connection (a presence or routing service), and a pub/sub layer to deliver messages from any server to the right one. Plan for reconnection with a cursor so clients catch up on missed events.

Practice. Design the delivery path for Design Live Comments when one stream has a million viewers.

Rate limiting Core

Rate limiting protects services from abuse and overload and shares capacity fairly. Common algorithms: token bucket (tokens refill at a fixed rate and allow short bursts), leaky bucket (smooths output to a steady rate), fixed window counters (simple but allow bursts at window edges) and sliding window logs or counters (more accurate).

In a distributed system the counters live in a shared fast store, or each node enforces a share of the limit locally to avoid a network call per request. Decide what to key on (user, API key, IP address), what to return (status 429 with a retry-after header), and whether to fail open or closed if the limiter itself is down.

Practice. Work through Design a Distributed Rate Limiter and compare a central counter with local limits.

Stage 3 Data storage

Intermediate9 topics

Goal. Choose the right store for each kind of data, and scale it with indexes, replicas and shards.

Relational databases and when to choose them Core

Relational databases store data in tables with a schema, join across tables, enforce constraints and run multi-row transactions. They are the right default for most business data: users, orders, payments and anything with relationships and correctness rules. A single well-tuned relational database on modern hardware handles a surprising amount of load, often thousands of writes and tens of thousands of reads a second.

Their limits appear with very high write rates, very large data sets and global distribution, where you must add replicas and shards. Even then, many large systems keep relational databases and shard them, rather than abandoning them. In interviews, choosing a relational store and explaining why is perfectly strong.

Practice. Model the tables for Design an E-commerce Checkout and mark which operations need a transaction.

NoSQL families: key-value, document, wide-column and graph Core

Key-value stores fetch a value by key extremely fast and scale out easily; they suit sessions, carts and lookups. Document stores keep flexible JSON-like records and query by fields; good when each record is read as a whole. Wide-column stores organise data by partition key and sorted clustering columns, giving very high write throughput for time-ordered data such as messages and events. Graph databases make multi-hop relationship queries natural.

The trade is usually fewer joins and weaker multi-record transactions for scale and predictable latency. You must design the data model around the queries: decide the access patterns first, then the keys. Picking a store because it is fashionable is a red flag to interviewers.

Practice. Design the message table for Design a Chat App in a wide-column store, choosing partition and sort keys.

Indexes Core

An index is an extra data structure that finds rows without scanning the table, most often a B-tree kept sorted by the indexed columns. Indexes make reads on those columns fast and make every write slower, because each index must be updated, so index what your queries filter and sort on, not everything.

Know composite indexes (column order matters: an index on country then city helps queries on country, or country and city, but not city alone), covering indexes that answer a query without touching the table, and the write-optimised log-structured merge trees used by many NoSQL stores. Missing indexes are the most common cause of a slow database in real systems.

Practice. Pick three queries from Design Yelp and write the index each one needs.

Replication Core

Replication keeps copies of data on several machines for durability, availability and read scaling. In leader-follower replication, one leader takes writes and streams changes to followers that serve reads. Replication can be synchronous (the write waits for followers: safer, slower) or asynchronous (faster, but a failover can lose the latest writes and followers lag behind).

Replica lag causes visible bugs: a user saves a profile and then sees the old version. Fixes include reading your own writes from the leader for a short time, or routing a user to the same replica. Multi-leader and leaderless designs accept writes in several places and must resolve conflicts, using quorums, version vectors or last-write-wins.

Practice. Study Design a Distributed Key-Value Store and explain how quorum reads and writes trade latency for consistency.

Sharding and partitioning Core

Sharding splits a data set across machines so each holds a part, letting writes and storage scale beyond one machine. Range partitioning keeps keys in order, which helps range queries but creates hot spots for sequential keys. Hash partitioning spreads keys evenly but scatters ranges. A lookup service or a deterministic function maps each key to its shard.

The shard key decides everything: it must match the main query pattern and spread load evenly. Queries that span shards become slow scatter-gather operations, and transactions across shards are hard. Plan for hot keys (one celebrity, one huge tenant) and for resharding as data grows, ideally by splitting data into many small virtual partitions from the start so they can be moved between machines.

Practice. In Design a Social Graph, choose a shard key for follower lists and explain what happens for an account with 100 million followers.

Consistent hashing Core

Simple hash partitioning with hash(key) mod N moves almost every key when N changes. Consistent hashing places servers and keys on a ring; each key belongs to the next server clockwise. Adding or removing a server moves only the keys between it and its neighbour, about 1/N of the data.

Each physical server takes many virtual nodes on the ring, which evens out load and lets bigger machines take more. Consistent hashing is used for distributed caches, partitioned key-value stores and load balancers that need stickiness. In interviews, explain the ring, virtual nodes and how replicas are placed on the next distinct servers clockwise.

Practice. Explain how Design a Distributed Cache adds a node without a flood of cache misses.

Transactions and isolation levels Recommended

A transaction groups operations so they all succeed or none do (atomicity), survive crashes once committed (durability) and do not see each other's partial work (isolation). Isolation comes in levels. Read committed hides uncommitted data. Snapshot isolation lets each transaction read a consistent snapshot. Serializable makes concurrent transactions behave as if run one at a time, at a cost.

Know the anomalies: lost updates when two transactions read, change and write the same value; write skew when two transactions each check a condition and both proceed, such as double-booking a meeting room. Prevent them with atomic conditional updates, row locks taken before reading, optimistic concurrency with version numbers, or serializable isolation.

Practice. In Design a Ticketing Platform (Ticketmaster), explain how two buyers are stopped from buying the same seat.

Object storage and blob handling Core

Object storage holds large, immutable files (images, video, backups, logs) cheaply and durably, addressed by key, with effectively unlimited capacity. Keep only metadata in your database and store the bytes in object storage, served through a CDN.

For uploads, let clients send files directly to object storage using short-lived pre-signed URLs instead of streaming through your servers, then process them asynchronously: virus scan, thumbnails, transcoding. Large files are uploaded in chunks so failures resume rather than restart, and identical chunks can be stored once (deduplication). Lifecycle rules move old objects to cheaper tiers.

Practice. Design the upload path for Design Dropbox, including chunking, deduplication and resuming a failed upload.

Search indexes and specialised stores Recommended

Some queries need purpose-built stores. Full-text search uses an inverted index mapping each term to the documents that contain it, with relevance scoring and filters. Time-series stores compress metrics by time and support downsampling. Geospatial indexes such as geohashes, quadtrees or hexagonal grids find things near a point. Vector indexes find the nearest embeddings for semantic search.

These usually sit alongside the primary database, fed by change streams, and are treated as rebuildable views. That gives each query the right engine, at the cost of keeping copies in sync and accepting that the index lags the source by seconds.

Practice. Study Design a Web Search Engine or Design a Vector Database and describe how the index is built and updated.

Stage 4 Caching

Intermediate4 topics

Goal. Make reads fast and cheap with caches, and keep them correct under failure and change.

Where to cache and caching patterns Core

Caches sit at many layers: the browser, the CDN, an in-process cache in the service, a shared cache such as Redis, and the database's own buffer. Each layer closer to the user saves more work but is harder to invalidate.

The common pattern is cache-aside: read from the cache, and on a miss read the database and fill the cache. Read-through puts that logic in the cache layer. Write-through writes to the cache and database together, keeping them in step at the cost of write latency. Write-behind writes to the cache and flushes to the database later: fast, but data can be lost. Cache-aside with a TTL is the right default for most designs.

Practice. Decide what to cache in Design a URL Shortener and estimate the hit rate needed to protect the database.

Eviction, TTLs and sizing Core

Caches hold less than the full data set, so they must evict. Least recently used (LRU) evicts what has not been read for longest and suits most workloads; least frequently used (LFU) protects popular items from one-off scans. A TTL limits how stale an entry can get.

Size the cache from the working set: often a small fraction of items gets most reads, so caching the hottest 10 to 20% can serve the large majority of requests. Measure hit rate, eviction rate and memory, and remember that a cache that gets too small suddenly sends a wave of misses to the database.

Practice. Implement an LRU cache in code, then explain how Design a Distributed Cache shards it across machines.

Invalidation and consistency Core

The hard part of caching is keeping it correct. Options: a short TTL that bounds staleness; deleting the cache key after a database write so the next read refills it; or updating caches from a change stream so every write propagates. Deleting is safer than updating the cached value, because two concurrent updates can leave the cache holding the older one.

Even delete-on-write has a race: a reader can fetch an old value, a writer updates and deletes, then the reader fills the cache with the old value. Versioned values or a short TTL as a safety net close that gap. Decide per data type how stale is acceptable; a product's view count can lag, its price at checkout cannot.

Practice. For Design a News Feed, decide what happens to cached feeds when a user deletes a post.

Stampedes, hot keys and cold starts Recommended

A cache stampede happens when a popular key expires and thousands of requests miss at once and hit the database together. Prevent it with request coalescing (one request rebuilds, others wait), early refresh before expiry, and jittered TTLs so keys do not expire together.

A hot key can overload the single cache node that owns it. Replicate hot keys to several nodes, add a small in-process cache in front, or split the key into copies with a suffix. After a restart a cold cache sends all reads to the database, so warm caches gradually and keep load shedding on the database tier.

Practice. In Design a Real-Time Gaming Leaderboard, explain how the top-100 list survives millions of reads a second.

Stage 5 Asynchronous processing and streaming

Intermediate6 topics

Goal. Decouple services with queues and streams, and get correct results despite retries and duplicates.

Message queues and background work Core

A queue lets a service hand off work and return immediately while workers process it later. Uses: sending emails, resizing images, calling slow third parties, smoothing traffic spikes. Producers and consumers scale independently, and if consumers fall behind, the queue absorbs the backlog instead of the system failing.

Details that matter: a visibility timeout hides a message while a worker processes it and returns it if the worker dies; acknowledgement deletes it when done; a dead-letter queue catches messages that keep failing so they do not block others. Scale workers on queue depth and age of the oldest message, not on CPU.

Practice. Design the pipeline in Design a Notification System with priorities, retries and a dead-letter queue.

Event streams and logs Core

A log-based stream stores events in an ordered, append-only log split into partitions. Consumers read at their own pace, track their position and can replay history. Many independent consumer groups can read the same events, which suits analytics, search indexing, notifications and audit trails built from one source.

Ordering is guaranteed only within a partition, so choose the partition key to keep related events together, such as all events for one order. The number of partitions caps consumer parallelism. Retention can be days or forever; with compaction, the log keeps the latest value per key and becomes a durable table.

Practice. Study Design a Distributed Message Queue and explain how partitions, replication and consumer offsets work.

Delivery guarantees and idempotency Core

Messaging systems offer at most once (may lose messages), at least once (may duplicate) or, within limits, exactly once processing. In practice you build on at least once and make consumers idempotent, so processing a message twice has the same effect as once.

Techniques: store processed message IDs and skip repeats; use natural idempotency such as setting a value rather than incrementing it; use conditional writes keyed on a version; and carry an idempotency key from the client through every hop. Exactly-once effect is a property of the whole pipeline, not of the broker alone.

Practice. In Design an Ad Click Aggregator, explain how duplicate click events are prevented from inflating counts.

The outbox pattern and change data capture Recommended

A service that writes to its database and then publishes an event can crash between the two, leaving them inconsistent. The outbox pattern writes the event into an outbox table in the same transaction as the data change; a relay process reads the outbox and publishes events, retrying until it succeeds.

Change data capture reads the database's own replication log and turns every committed change into an event, with no application changes. Both give a reliable stream of changes that keeps caches, search indexes, analytics and other services in sync with the source of truth.

Practice. Use the outbox pattern in Design a Payment System so a recorded payment always produces exactly one confirmation event.

Batch and stream processing Recommended

Batch processing runs over a bounded data set on a schedule, such as nightly reports or rebuilding a search index: simple, efficient and easy to rerun. Stream processing handles events continuously with seconds of delay, such as fraud scoring, live dashboards and trending topics.

Streaming introduces windows (tumbling, sliding, session), event time versus processing time, late events handled with watermarks, and state that must be checkpointed so a crash resumes correctly. Many systems combine both: a stream gives fast approximate answers and a batch job later produces the corrected, final numbers.

Practice. Compare the streaming and batch paths in Design Best-Seller Rankings and say which answer users see when.

Event sourcing and CQRS Optional

Event sourcing stores every change as an immutable event, and current state is rebuilt by replaying them. You get a full audit trail, can answer questions about the past and can build new views later. The costs are complexity, schema evolution of old events and the need for snapshots to keep replays fast.

CQRS (command query responsibility segregation) separates the write model from one or more read models, each shaped for its queries and updated from events. They pair well in ledgers, trading and order systems, but are overkill for simple CRUD applications; say so in interviews.

Practice. Explain how Design a Stock Exchange or Design a Digital Wallet uses an append-only log as the source of truth.

Stage 6 Consistency and coordination

Advanced5 topics

Goal. Reason about what users see under concurrency and failure, and coordinate machines safely.

CAP, PACELC and consistency models Core

During a network partition, a replicated store must choose between staying available (and risking stale or conflicting data) and staying consistent (and refusing some requests). That is the CAP theorem. PACELC extends it: else, when there is no partition, you still trade latency against consistency, because waiting for replicas takes time.

Consistency comes in models. Strong (linearizable) consistency means every read sees the latest write. Eventual consistency means replicas converge if writes stop. In between are read-your-writes, monotonic reads and causal consistency, which often give users a sensible experience at much lower cost. Choose per feature: balances and inventory need strong guarantees; likes and view counts do not.

Practice. For Design Airbnb, decide which data needs strong consistency and which can be eventually consistent.

Distributed transactions: two-phase commit and sagas Core

When one operation spans several services or databases, a local transaction is not enough. Two-phase commit asks every participant to prepare, then tells all to commit; it gives atomicity but blocks if the coordinator fails and couples services tightly, so it is rare between microservices.

A saga breaks the operation into local steps, each with a compensating action that undoes it: reserve stock, charge the card, create the shipment, and if shipping fails, refund and release stock. Sagas are coordinated by a central orchestrator or by events between services. They give eventual consistency, so design for intermediate states the user may see.

Practice. Write the saga for Design a Food Delivery App from order to delivery, with a compensation for each step.

Consensus and leader election Recommended

Many systems need machines to agree: which node is leader, what the cluster configuration is, whether a write is committed. Consensus algorithms such as Raft and Paxos let a majority of nodes agree despite some failing; a cluster of five tolerates two failures. They are used inside coordination services, replicated databases and stream brokers.

You rarely implement consensus yourself. Instead you use a coordination service for leader election, configuration and membership. Know why a majority is needed: two halves of a split cluster cannot both have a majority, so only one side can elect a leader, which prevents split-brain.

Practice. In Design a Distributed Job Scheduler, explain how only one scheduler fires each job when several are running.

Locks, leases and fencing Recommended

A distributed lock gives one process exclusive access to a resource. It should be a lease that expires, so a crashed holder does not block forever. The danger is that a holder can stall past its lease while someone else acquires it, and both act. A fencing token, a number that increases with each grant and is checked by the resource, rejects the stale holder.

Often you can avoid locks: conditional writes (only update if the version is still 7), unique constraints, single-writer partitions where one consumer owns each key, or queues that serialise work per key. Prefer these; they are simpler and fail more safely.

Practice. In Design an Online Auction Platform, explain how concurrent bids on the same item are ordered correctly without a global lock.

Unique IDs and clocks Core

Distributed systems need unique IDs without a single counter. Options: random UUIDs (simple, but unordered and large), database sequences per shard, ranges handed out in blocks, or time-ordered IDs combining a timestamp, a machine ID and a sequence number, which sort roughly by creation time and fit in 64 bits.

Clocks on different machines drift, so wall-clock time cannot order events precisely across machines. Use logical clocks or version numbers for ordering, keep time-based IDs tolerant of small clock steps backwards, and never rely on timestamps alone to decide which of two concurrent writes wins if correctness matters.

Practice. Work through Design a Unique ID Generator and explain what happens if a machine's clock jumps backwards.

Stage 7 Reliability and operations

Advanced5 topics

Goal. Keep the system up through failures, overload and releases, and know when it is not.

Timeouts, retries and backoff Core

Every network call needs a timeout; without one, a slow dependency ties up threads until the whole service stops. Retries recover from brief failures but can multiply load during an outage, so retry only idempotent operations, use exponential backoff with jitter, cap the number of attempts and share a retry budget across the service.

Retries at every layer multiply: three layers each retrying three times turn one failure into 27 calls. Retry at one layer, usually closest to the user, and pass deadlines downstream so a service does not keep working on a request the caller has already given up on.

Practice. For any service in Design an E-commerce Checkout, set a timeout and retry policy for each dependency and justify it.

Circuit breakers, bulkheads and load shedding Core

A circuit breaker stops calling a failing dependency for a while after errors cross a threshold, returning a fallback immediately, then lets a few test requests through to see if it has recovered. Bulkheads isolate resources, such as separate connection pools per dependency, so one slow dependency cannot consume everything.

Under overload, load shedding rejects some requests early, preferring low-priority traffic, so the rest are served well instead of all being served badly. Graceful degradation turns off non-essential features, such as recommendations or live counts, to protect the core path.

Practice. In Design a News Feed, decide what the feed shows when the ranking service is down.

Multi-region design and disaster recovery Recommended

One region protects against server and zone failures; surviving a whole region failing needs a second region. Active-passive runs one region and replicates data to a standby, with a recovery time of minutes and possible loss of recent writes. Active-active serves traffic from both, needing data partitioned by home region or conflict handling, with near-zero recovery time and much more complexity.

Define the recovery point objective (how much data you can lose) and recovery time objective (how long you can be down) with the business, then choose. Keep enough capacity to absorb the other region's load, and test failover regularly, because untested failover usually fails.

Practice. Extend Design a Payment System to two regions and state the recovery point and recovery time it achieves.

Observability: metrics, logs and traces Core

You cannot run what you cannot see. Metrics are cheap numbers over time: request rate, error rate, latency percentiles and saturation for every service. Logs are detailed records of events, best structured as JSON with a request ID. Traces follow one request across services and show where its time went.

Define service level objectives, such as 99.9% of requests succeed within 300 ms, and alert when the error budget burns too fast, not on every CPU spike. In interviews, end every design with the three or four metrics you would watch and what would page someone.

Practice. Study Design a Metrics Monitoring and Alerting System and list the metrics you would alert on for a chat service.

Deployments and safe change Recommended

Most outages follow a change. Release in small steps: rolling deploys replace servers in batches, blue-green switches traffic between two full environments, and canary releases send a small share of traffic to the new version and watch its metrics before continuing. Feature flags separate deploying code from turning features on.

Database changes need extra care: make them backwards compatible (add a column, deploy code that uses it, backfill, then remove the old one later) so old and new code run safely side by side. Automate rollback when error rates rise.

Practice. Plan how you would migrate Design a URL Shortener to a new database with no downtime.

Stage 8 Security and specialised topics

Advanced5 topics

Goal. Secure designs by default, and know the patterns behind geo, search, ranking and AI systems.

Authentication, authorisation and multi-tenancy Core

Authentication proves who a caller is: passwords with strong hashing, single sign-on, and tokens such as signed session tokens with short lifetimes and refresh. Authorisation decides what they may do: role-based access, attribute-based rules and per-resource permissions checked on every request, at the service that owns the data.

In multi-tenant systems, every query must be scoped to the tenant, ideally enforced by the data layer rather than remembered in each query. Isolate noisy tenants with quotas, and consider dedicated resources for the largest or most regulated customers.

Practice. Add sharing permissions to Design Google Docs: view, comment and edit, for users, groups and public links.

Encryption, secrets and abuse prevention Recommended

Encrypt data in transit with TLS everywhere, including between internal services, and at rest with managed keys. Keep secrets in a secrets manager, never in code. Minimise personal data, define retention and support deletion requests.

Public systems also need abuse defences: rate limits per user and IP, bot detection, input validation, safe handling of uploaded files, and protection against enumeration of IDs. Mentioning these briefly in the wrap-up shows maturity without spending deep-dive time on them.

Practice. List the abuse cases for Design Pastebin and the cheapest defence for each.

Geospatial indexing and location services Recommended

Finding things near a point needs a spatial index. Geohashes encode latitude and longitude into a string where shared prefixes mean nearby cells, so a prefix query finds a region. Quadtrees split the map recursively where points are dense. Hexagonal grids give cells with uniform neighbours, useful for pricing and supply zones.

Moving objects, such as drivers sending a location every few seconds, need an in-memory index updated at high write rates, often partitioned by region, with the durable history written asynchronously. Search for nearby items by checking the user's cell and its neighbours, then filtering by exact distance.

Practice. Design driver location tracking and matching in Design Uber, including what happens at cell boundaries.

Search, ranking and recommendation systems Optional

Search and recommendation systems usually work in stages. Retrieval narrows millions of items to hundreds quickly, using inverted indexes, nearest-neighbour search over embeddings or simple rules. Ranking scores those candidates with a richer model using user, item and context features. Re-ranking applies business rules such as diversity, freshness and policy filters.

Features are precomputed in batch, updated by streams for freshness, and served from a low-latency store. Quality is measured offline with ranking metrics and online with experiments. Mention feedback loops: the system learns from what it showed, so add exploration.

Practice. Walk through Design a Recommendation Feed stage by stage with the latency budget for each.

AI and LLM systems Optional

Systems built on large language models add new building blocks. Retrieval-augmented generation searches your own documents and passes the best passages to the model, so answers use current, private data. Model serving runs on GPUs, where batching requests, streaming tokens and caching repeated prompts drive both latency and cost. A gateway handles routing between models, quotas, logging and safety filters.

Evaluation is a system in itself: test sets, automated scoring, human review and monitoring of live quality. Treat cost per request, latency to the first token and safety as first-class non-functional requirements.

Practice. Design Design a RAG Question-Answering System and state how you would measure answer quality before and after launch.

Stage 9 Low-level design

Intermediate4 topics

Goal. Model a problem as clean classes and state, and write extensible working code under time pressure.

Approach for low-level design rounds Core

Low-level design rounds ask you to model one program, such as a parking lot, an elevator controller or an expense-sharing app, and often to write working code. Use a fixed approach: clarify requirements and scope (5 to 10 minutes), identify the core entities and their responsibilities, sketch classes and interfaces, define the main flows, then code the core and leave clear extension points.

Interviewers score modelling (are responsibilities in the right classes?), extensibility (can a new vehicle type or pricing rule be added without rewriting?), correctness including edge cases, and code quality: names, small methods, no duplicated logic. A smaller design that runs beats a large one that does not.

Practice. Design Design a Parking Lot in 90 minutes with working code, then add a new vehicle type and a new pricing rule.

Object-oriented principles: SOLID and composition Core

The SOLID principles are a useful checklist. Single responsibility: each class has one reason to change. Open-closed: add behaviour by adding classes, not editing working ones. Liskov substitution: subclasses must work wherever the parent does. Interface segregation: small, focused interfaces. Dependency inversion: depend on abstractions, so you can swap implementations and test easily.

Prefer composition over deep inheritance: a vehicle has a pricing strategy rather than being a subclass for each price rule. Keep data and the rules that change it together, and avoid god classes that know everything.

Practice. Review your parking lot code against each SOLID principle and refactor the worst violation.

Design patterns that come up Recommended

A few patterns appear in most low-level design rounds. Strategy swaps algorithms such as pricing or slot allocation. State models objects whose behaviour depends on their state, such as a vending machine or an ATM. Observer notifies subscribers of changes. Factory creates the right subtype. Singleton gives one shared instance, used sparingly. Command wraps requests so they can be queued or undone.

Name a pattern only when it solves a real problem in the design; forcing patterns in reads as memorised. Explain what change the pattern makes easy.

Practice. Model Design a Vending Machine or Design an ATM with the State pattern and draw the state transitions.

Concurrency in low-level design Recommended

Many low-level problems have shared state: seats being booked, slots being assigned, log lines written from many threads. Identify the shared data and protect it with the narrowest safe mechanism: atomic operations, a lock around the critical section, concurrent collections, or a single thread that owns the state and receives requests through a queue.

Watch for check-then-act races (checking a seat is free and booking it must be one atomic step), deadlocks from acquiring locks in different orders, and holding locks while doing slow work. Explain how your design behaves when two users act at the same moment.

Practice. Make seat booking in Design a Movie Ticket Booking System safe under concurrent requests, with a temporary hold that expires.

Practice problems

Every problem below has a full walkthrough in the system design practice workspace, where you can write your own design first, use hints and compare with a reference answer. Start with the foundations group: almost every other problem reuses those building blocks.

Study plan

1. Week 1Framework and foundations

   • Read stages 1 and 2 of this page and learn the numbers table until you can estimate without notes.

   • Design Pastebin and a URL shortener using the six-step framework, out loud, with a 45-minute timer.

   • Write down the questions you asked in step 1 and reuse them as a checklist.

2. Week 2Data and caching

   • Study stages 3 and 4: storage choice, indexes, replication, sharding and caching.

   • Practise a distributed cache, a key-value store and a unique ID generator.

   • For each design, explain your partition key and what happens when one key gets very hot.

3. Weeks 3–4Asynchronous systems and classic products

   • Study stages 5 and 6: queues, streams, delivery guarantees, sagas and coordination.

   • Practise a notification system, a chat app, a news feed and a video platform.

   • For each, draw the write path and the read path separately and name the consistency each one needs.

4. Week 5Reliability, money and marketplaces

   • Study stages 7 and 8: failure handling, multi-region, observability and security.

   • Practise a payment system, a ticketing platform and a ride-hailing app, where correctness under concurrency matters most.

   • For each, list five failure modes and how the design survives them.

5. Week 6Low-level design

   • Study stage 9 and design a parking lot, an elevator system and a meeting room scheduler with classes and working code.

   • Time yourself: 10 minutes for requirements and classes, 60 for code, 10 for extensions.

6. Weeks 7–8Mock interviews and your target area

   • Do at least four full mock interviews, ideally with a peer playing interviewer and changing requirements halfway.

   • Add problems from your target area: infrastructure, commerce, media or AI systems.

   • Answer every question below out loud and track progress on your progress page and study plan.

Interview questions

These are the conceptual questions interviewers ask most, inside a design round or as quick-fire questions. Answer out loud before opening each one.

Common mistakes

• Drawing boxes before agreeing requirements. Five minutes of questions saves the whole interview from solving the wrong problem.
• Skipping estimates, or doing them and never using the results. Every number should lead to a decision.
• Naming technologies instead of explaining them. Say what a component does and why it fits, not only its product name.
• Starting with a complex, fully scaled design. Prove a simple design works, then scale the parts the numbers say need it.
• Ignoring failure. Interviewers will ask what happens when a node, a region or a dependency fails; have an answer for each part.
• Spending the deep dive on easy parts, such as the load balancer, instead of what makes this problem hard.
• Never stating trade-offs. Every choice has a cost; saying it out loud is most of what senior interviewers score.
• Talking without checking in. Pause after each step and ask if the interviewer wants to go deeper anywhere.

Ready-for-interview checklist

• I can run the six-step framework on an unseen prompt within 45 minutes.
• I can convert daily users into peak requests per second, storage and bandwidth in two minutes.
• I can explain when to use SQL, a key-value store, a document store, a search index and object storage.
• I can design replication and sharding for a data set and explain hot keys and resharding.
• I can choose a caching pattern and handle invalidation and stampedes.
• I can explain at-least-once delivery, idempotent consumers and the outbox pattern.
• I can explain CAP, consistency models and when strong consistency is required.
• I can design retries, timeouts, circuit breakers and graceful degradation.
• I have practised at least fifteen problems from the list above, including a feed, a chat app, a payment system and a low-level design.
• I can describe the monitoring, alerts and rollout plan for any design I draw.

Related pages

• System design practiceWrite your design, use hints, compare with a reference answer.
• Software Engineer roadmapThe full path, from coding rounds to design rounds.
• Back End Engineer roadmapAPIs, databases and scaling in depth.
• Software Architect roadmapArchitecture styles, trade-offs and long-term design.
• Company interview guidesHow design rounds differ at each company.
• Study planTurn this page into a daily schedule.

FAQ