Top 50 High Level Design Interview Questions (2026)

High Level Design is the architecture of a system: the major components, how they connect, and how data flows between them, described without writing code. It's the blueprint you reason about before implementation.

It matters because architecture decisions are the hardest to change later. Choosing the wrong data store, missing a scaling bottleneck, or ignoring a single point of failure at the design stage costs far more to fix in production. HLD is where you catch those problems early, on a whiteboard, when they're still cheap.

HLD is the system's architecture: what the major components are, how they talk, and where data lives. LLD is the internal design of each component: its classes, methods, interfaces, and data structures.

Think of HLD as the map of a city and LLD as the floor plan of one building. A prompt like 'design a news feed' wants HLD; 'design the classes for an elevator system' wants LLD. Pitching your answer at the right altitude is part of the signal.

Functional requirements are what the system does: the features and behaviors. For a URL shortener, that's 'create a short link' and 'redirect to the original'. Non-functional requirements are how well it does them: scale, latency, availability, consistency, durability.

In an HLD interview you clarify both up front, because the non-functional side drives the architecture. 'Handle 10,000 requests per second with under 100ms latency and 99.99% availability' shapes your design far more than the feature list does.

Use a framework instead of diving in. Clarify requirements and scale, do a quick back-of-the-envelope estimate, draw the high-level components and the request flow, then deep dive into one part and discuss trade-offs.

For a URL shortener: confirm the features (shorten, redirect, maybe analytics), estimate the read-to-write ratio (reads dominate heavily), pick a key-generation scheme, choose a data store keyed by short code, add a cache for hot links, and put it behind a load balancer. Narrate each choice.

A load balancer sits in front of your servers and spreads incoming requests across them, so no single server is overwhelmed. It also health-checks the servers and stops routing traffic to any that fail, which keeps the system available.

You need one the moment you run more than one server, which is the basis of horizontal scaling. It also gives you a single entry point for TLS termination and lets you add or remove servers without clients noticing.

Vertical scaling (scaling up) means giving one machine more power: more CPU, RAM, or faster disks. It's simple but hits a hard ceiling, gets expensive fast, and leaves that one machine as a single point of failure.

Horizontal scaling (scaling out) means adding more machines and spreading load across them behind a load balancer. It scales much further and adds redundancy, but it needs the app to be stateless and forces you to handle distributed-system problems. Large systems scale out.

A stateless service keeps no client-specific data between requests in its own memory. Every request carries what it needs, and any instance can handle any request identically. Session data lives in a shared store like a cache or database, not on the server.

It helps scaling because you can add or remove instances freely behind a load balancer, and one instance failing loses nothing. Stateful servers, where a user's session lives on one specific box, break the moment you try to spread traffic or lose a machine.

SQL (relational) databases store structured data in tables with a fixed schema and support joins, transactions, and strong consistency. They're the right default when relationships and data integrity matter, like payments or orders.

NoSQL is a family (key-value, document, wide-column, graph) built for scale and flexibility. They handle huge volumes, flexible or changing schemas, and simple access patterns well, often trading some consistency for availability and speed. The choice is about access patterns and consistency needs, not 'newer is better'.

A cache stores a copy of data closer to where it's needed and faster to read than the source, so repeated reads skip the slow path. An in-memory cache like Redis serving hot database rows is the classic example.

You cache at several layers: the browser, a CDN for static assets at the edge, an application-level cache for computed results, and a database read cache for hot queries. Each layer removes load from the slower thing behind it. The catch is keeping cached data from going stale.

A CDN (Content Delivery Network) is a network of servers spread across many locations that cache and serve content from a point geographically close to each user. A user in Tokyo gets assets from a Tokyo edge instead of a server in Virginia.

You use it for static and cacheable content: images, video, CSS, JavaScript, and increasingly cacheable API responses. It cuts latency, reduces load on your origin servers, and absorbs traffic spikes. It doesn't help much for highly dynamic, per-user data that can't be cached.

An API is the contract for how clients talk to your service: the endpoints, the request and response shapes, and the rules. In HLD it's the boundary between components. REST models everything as resources with standard HTTP verbs (GET, POST, PUT, DELETE) acting on URLs.

RPC-style APIs (like gRPC) model calls as remote function invocations, which can be more efficient and strongly typed, and suit internal service-to-service traffic. REST is common for public and web-facing APIs because it's simple and cacheable. The practical answer: REST for external, gRPC for high-throughput internal calls.

Replication keeps copies of the database on multiple machines. The common pattern is one primary that takes writes and several replicas that copy from it and serve reads, which spreads read load and gives you a standby if the primary fails.

It's used for two reasons: read scalability (many replicas answering reads) and availability (promote a replica if the primary dies). The cost is replication lag, replicas can be slightly behind the primary, so a read right after a write might see stale data.

Latency is how long one request takes, measured in milliseconds. Throughput is how many requests the system handles per unit of time, measured in requests per second. They're related but not the same.

A system can have high throughput and high latency at once: think of a wide pipe that's also long. In design you optimize for the one the requirements demand, low latency for a search box, high throughput for a batch pipeline, and you measure latency at percentiles (p99) because averages hide the slow tail.

Availability is the percentage of time a system is up and serving requests. The 'nines' are shorthand for availability targets: 99.9% (three nines) allows about 8.7 hours of downtime a year, and 99.99% (four nines) allows about 52 minutes.

Each extra nine costs a lot more engineering: redundancy, failover, multi-zone deployment, and careful operations. In design you match the target to the business need, a payments system needs more nines than an internal report, and you achieve it by removing single points of failure.

A single point of failure (SPOF) is any component with no backup whose failure takes down the whole system. A lone database, one load balancer, or a single server all qualify. Finding SPOFs is a core part of reviewing an HLD.

You remove them with redundancy: run multiple instances of each component, replicate data, put load balancers in a redundant pair, and spread across availability zones so one zone failing doesn't matter. The habit to show is scanning your own diagram and asking 'what happens if this box dies'.

Synchronous means the caller sends a request and waits for the response before continuing, like a normal API call. It's simple and gives an immediate answer, but the caller is blocked and coupled to the callee's availability and speed.

Asynchronous means the caller hands off the work (often to a queue) and doesn't wait, the result comes later or via a callback. It decouples services, absorbs spikes, and survives a slow downstream, at the cost of more complexity and no instant result. Use async for slow or non-urgent work like sending emails.

A message queue is a buffer between a producer that creates work and a consumer that processes it. The producer drops messages on the queue and moves on; consumers pull and process at their own pace. Kafka, RabbitMQ, and SQS are common examples.

You use one to decouple services, absorb traffic spikes (the queue holds the backlog instead of crashing the consumer), and process work asynchronously with retries. It smooths a bursty load into a steady stream and lets a slow downstream catch up instead of failing.

A monolith is one deployable application containing all the features. It's simple to build, test, and deploy early on, but as it grows a change anywhere means redeploying everything, and teams start stepping on each other.

Microservices split the system into small independent services that deploy and scale separately, each owned by a team. That helps large organizations move fast, but it adds real cost: network calls, distributed data, and operational overhead. The honest answer is 'start monolith, split when the pain justifies it', not 'microservices always'.

An API gateway is a single entry point that sits in front of your services and routes each incoming request to the right one. Instead of clients calling a dozen services directly, they call the gateway, which forwards the request and returns the response.

It centralizes cross-cutting concerns so every service doesn't reimplement them: authentication, rate limiting, request routing, TLS termination, and sometimes response aggregation and caching. In a microservices system it's the front door. The trade-off is that it can become a bottleneck or a single point of failure, so you run it redundantly.

CAP says a distributed system can guarantee at most two of three properties: consistency (every read sees the latest write), availability (every request gets a response), and partition tolerance (it keeps working despite network splits). Since network partitions are unavoidable, you really choose between consistency and availability when one happens.

In practice you pick per use case: a banking ledger favors consistency (refuse the operation rather than show wrong balances), while a social feed favors availability (show slightly stale posts rather than an error). The theorem isn't a whole-system label; different parts of one system can make different choices.

Strong consistency means every read returns the most recent write; once data is written, all clients see it immediately. It's easier to reason about but costs latency and availability, because the system must coordinate across replicas before answering.

Eventual consistency means replicas converge over time, so a read right after a write might return an old value, but they'll agree eventually. It buys availability and low latency at massive scale. Many systems sit in between with tunable consistency, choosing per operation, strong for a checkout, eventual for a like count.

Sharding splits a database horizontally across multiple machines, each holding a subset of the rows, so you scale writes and storage past what one machine can hold. A shard key decides which shard a given row lands on.

The shard key makes or breaks it. A good key spreads data and traffic evenly and keeps related data together so common queries hit one shard. A bad key creates hot shards (one machine overwhelmed) or scatters a query across every shard. User ID often works; a low-cardinality field like country usually doesn't.

The common patterns are cache-aside (the app checks the cache, and on a miss loads from the database and populates the cache), write-through (writes go to cache and database together, keeping them in sync), and write-back (write to cache first, flush to the database later for speed, at the risk of loss).

Invalidation is the hard part. You set TTLs so entries expire, explicitly evict on write, or use versioned keys. The pitfalls are stale reads, the thundering herd when a hot key expires and every request stampedes the database at once, and cache stampede protection like request coalescing or staggered TTLs.

Consistent hashing maps both keys and servers onto a ring. A key belongs to the next server clockwise on the ring. When you add or remove a server, only the keys near that point move, instead of nearly all keys remapping the way plain modulo hashing would.

It solves the rebalancing problem in distributed caches and databases: with modulo hashing, changing the server count reshuffles almost everything and blows away the cache. Consistent hashing keeps disruption small. Virtual nodes (many points per server on the ring) smooth out uneven distribution.

A rate limiter caps how many requests a client can make in a window, protecting the system from abuse and overload. The common algorithms are token bucket (tokens refill at a fixed rate, each request spends one, allowing bursts up to the bucket size), leaky bucket (a fixed drain rate that smooths bursts), and sliding window counters for accuracy.

For a distributed system, the counters live in a shared fast store like Redis so all servers enforce the same limit, keyed by user or IP. You return HTTP 429 when the limit is hit, ideally with a Retry-After header. Token bucket is the usual default because it allows short bursts while capping the sustained rate.

For read-heavy systems (most web apps, feeds), you add read replicas, cache aggressively, and use a CDN, because reads vastly outnumber writes. The primary handles writes while replicas and caches soak up reads, and eventual consistency is often acceptable for reads.

For write-heavy systems (metrics ingestion, logging), replicas and caches don't help the bottleneck. You shard to spread writes, buffer through a queue so bursts don't overwhelm storage, batch writes, and pick a store built for high write throughput like a wide-column database. Knowing the read/write ratio drives the whole architecture.

Clarify first: shorten a long URL to a short code, redirect on lookup, maybe track clicks, and note that reads (redirects) hugely outnumber writes (creations). Generate a unique short code, either a base-62 encoding of an auto-increment ID or a hash with collision handling, and store the mapping of code to long URL.

The read path is the hot one: a redirect looks up the code, so keep the mapping in a fast key-value store and cache hot codes in memory, all behind a load balancer. Because it's read-heavy and rarely updated, aggressive caching and replicas scale it easily. Add a CDN or edge layer if global latency matters.

Clarify: users follow others and see a feed of recent posts, reads dominate, and freshness matters but slight staleness is fine. The core trade-off is fan-out on write versus fan-out on read. Fan-out on write pushes each new post into every follower's precomputed feed, so reads are instant. Fan-out on read builds the feed by pulling from followed users at read time.

Fan-out on write is fast to read but expensive for users with millions of followers (one post updates millions of feeds). Fan-out on read is cheap to write but slow to read. Real systems use a hybrid: precompute for normal users, pull at read time for celebrity accounts. Cache feeds, and use a queue for the fan-out work.

Round robin cycles through servers evenly and works when requests cost about the same. Least connections routes to the server with the fewest active connections and handles uneven request durations better. Weighted variants send more traffic to bigger servers.

IP hash or a session cookie gives stickiness so a client keeps hitting one server, which you need only if the server holds session state, and the better fix is usually to make the service stateless instead. Layer 4 balancing works on TCP, layer 7 can route by URL or header, which enables path-based routing to different services.

An index is a separate data structure, usually a B-tree, that lets the database find rows by a column's value without scanning the whole table. It turns a slow full-table scan into a fast lookup for queries that filter or sort on the indexed column.

The trade-off is that indexes speed reads but slow writes, because every insert, update, or delete must also update the index, and they take extra storage. So you index the columns your queries actually filter and join on, not every column. Over-indexing a write-heavy table quietly hurts performance.

ACID (Atomicity, Consistency, Isolation, Durability) is the guarantee set of traditional relational transactions: operations are all-or-nothing, leave the database valid, don't interfere, and survive crashes. It's what you want for money and orders.

BASE (Basically Available, Soft state, Eventual consistency) is the looser model many NoSQL systems adopt to scale: prioritize availability, accept that state is in flux, and let replicas converge over time. The choice mirrors CAP, ACID leans consistency, BASE leans availability, and you match it to how much the data can tolerate being briefly wrong.

An operation is idempotent if doing it many times has the same effect as doing it once. In distributed systems, retries are unavoidable, networks drop responses, so clients resend, and without idempotency a retried 'charge card' could bill twice.

You make operations idempotent with idempotency keys: the client sends a unique key with the request, the server records it, and a repeat with the same key returns the first result instead of acting again. It's essential anywhere a retry could cause a duplicate side effect, especially payments and order creation.

Short polling has the client ask 'anything new?' on a timer, which is simple but wasteful and adds latency. Long polling holds the request open until there's data or a timeout, cutting empty requests but still reconnecting each time. Both run over normal HTTP.

WebSockets open a persistent two-way connection so the server pushes updates instantly, which suits chat, live dashboards, and gaming. Server-Sent Events are a lighter one-way option for server-to-client streams. The trade-off is that persistent connections cost server resources and need sticky routing or a pub/sub layer to scale across many servers.

Estimate the numbers that drive the design: requests per second, storage, and bandwidth. Start from users and activity, round hard, and state every assumption. For example, 100 million daily users each making 10 requests is a billion requests a day, roughly 12,000 per second average, and you'd plan for a few times that at peak.

The point isn't precision, it's showing you can reason about orders of magnitude and spot the bottleneck. Convert daily totals to per-second, multiply record size by volume for storage, and check whether reads or writes dominate. Interviewers care about the method and stated assumptions far more than the exact figure.

A forward proxy sits in front of clients and makes requests on their behalf, hiding the client from the server. It's used for things like filtering outbound traffic or caching on the client side of a network.

A reverse proxy sits in front of servers and takes client requests, then forwards them to the right backend. It's the workhorse of web architecture: it does load balancing, TLS termination, caching, compression, and request routing, and it hides your backend servers behind one entry point. Nginx and Envoy are common examples.

Drive the conversation with a clear structure so a sprawling prompt stays under control. Clarify scope and non-functional targets, estimate scale, sketch the high-level components and data flow, then deep-dive the two or three parts that carry the real risk: the data model, the hot path, and the failure modes.

The strong move is prioritizing. You can't design everything in 45 minutes, so The bottleneck, spend time where it matters, and explicitly defer the rest ('I'd also need auth and analytics, but the interesting scaling problem is the feed, so let me go deep there'). Narrate trade-offs at every choice, because that reasoning is what's evaluated.

In a microservices world you usually can't use a single database transaction across services, so you use the saga pattern: break the operation into a sequence of local transactions, each with a compensating action that undoes it if a later step fails. An order saga might reserve inventory, charge payment, then ship, and roll back the earlier steps if any fails.

Sagas come in two flavors: choreography (services react to each other's events, no central coordinator, simpler but harder to trace) and orchestration (a central coordinator drives the steps, clearer but adds a component). Two-phase commit exists but is avoided at scale because it blocks and creates a coordinator SPOF. The reality you accept is eventual consistency across services.

Accept that at scale you often can't have strong consistency everywhere, then hide the gap with product and technical patterns. Read-your-own-writes consistency (route a user's reads to where their write landed, or serve their own action from a local cache) makes the system feel immediate even while replicas catch up.

Technically, you version data to resolve conflicts (last-write-wins, vector clocks, or CRDTs for mergeable state), and you design UIs that tolerate slight lag, an optimistic update that shows the like immediately while it propagates. The skill is choosing which operations genuinely need strong consistency (money) and letting the rest be eventual (counts, feeds).

A hot partition is a single shard or key taking disproportionate traffic, so one node saturates while the rest sit idle, defeating the point of sharding. It comes from a skewed access pattern: a celebrity user, a viral item, or a poorly chosen partition key.

Fixes depend on the cause: add a random suffix to spread a hot write key across sub-partitions, cache the hot read key so most traffic never reaches the shard, or pick a higher-cardinality partition key. For a known hot entity like a celebrity, special-case it with its own dedicated handling. Detecting the skew early, through per-partition metrics, is half the battle.

Clarify: multiple channels (push, email, SMS), high volume, must not lose notifications, and should respect user preferences and rate limits. The core shape is a queue-driven pipeline: services publish notification events to a queue, workers pull them, apply user preferences and deduplication, then hand off to channel-specific senders that call the provider APIs.

Decoupling with a queue is what lets it absorb spikes and retry failed sends without blocking the caller. Add a preference service so users can opt out per channel, a template service, rate limiting to avoid spamming a user, and idempotency so a retry doesn't send twice. Third-party providers fail, so retries with backoff and a dead-letter queue for poison messages matter.

Assume every component fails and every network call can time out, then contain the damage. Use timeouts on every remote call so a slow dependency doesn't hang your threads, retries with exponential backoff and jitter for transient failures, and circuit breakers that stop calling a failing dependency to let it recover and to fail fast.

Beyond that: bulkheads isolate resources so one struggling dependency can't consume all your threads, graceful degradation serves a reduced experience instead of an error (a cached or default response), and redundancy plus health checks handle instance loss. The mindset is that partial failure is normal, so the system should degrade, not collapse.

Backpressure is what happens when a component receives work faster than it can process it. Without handling, its queues grow unbounded, memory fills, latency climbs, and it eventually crashes, often taking upstream services with it in a cascading failure.

You handle it by signaling upstream to slow down or by shedding load: bounded queues that reject or drop when full, rate limiting at the edge, and load shedding that drops low-priority requests to protect the core. In streaming systems, consumers pull at their own pace (as Kafka does) so a slow consumer can't be overwhelmed. The principle is that a healthy system fails some requests deliberately rather than collapsing entirely.

The strategies are range partitioning (split by key ranges, good for range scans, risks hot ranges), hash partitioning (hash the key for even spread, but range queries scatter), and consistent hashing (minimizes movement when nodes change). The right one depends on your access patterns and how often the cluster resizes.

Repartitioning is painful because moving data is slow and risky, so you design to avoid it: pick a key with high cardinality and even distribution, over-provision the logical partition count so you rebalance logical partitions across physical nodes without rehashing keys, and prefer consistent hashing so adding a node moves only a slice. The mistake is a low-cardinality key that forces a full reshuffle later.

A CDN caches content at edge locations near users, cutting latency and offloading the origin. At design time you decide what's cacheable, static assets always, and increasingly dynamic but cacheable API responses with short TTLs, and how to invalidate it (purge on change or version the URL). Cache hit ratio at the edge is a real design metric.

Edge computing pushes logic itself to those locations: request routing, auth checks, personalization, and A/B logic run at the edge instead of a central region. This slashes latency for global users but constrains you to a lighter runtime and complicates state, since edge nodes are far from your primary data. You use the edge for latency-sensitive, low-state work and keep heavy state central.

Clarify: one-to-one and group messages, delivery and read receipts, online presence, message history, and low latency. Clients hold a persistent WebSocket to a connection layer of stateless gateway servers. Because a WebSocket lives on one server, you need a way to route a message to whichever server holds the recipient's connection, usually a pub/sub layer or a registry mapping user to server.

Messages persist to a store optimized for the write-heavy, time-ordered access pattern (a wide-column store keyed by conversation and time). A queue handles fan-out for group chats and offline delivery. Presence is a fast expiring key in a cache. The hard parts are connection routing across many gateway servers, ordering, and delivering to offline users when they reconnect.

Design in the three pillars from the start: metrics (aggregated numbers for dashboards and alerts), logs (structured, with a correlation ID on every line so you can follow one request), and distributed traces (a request's path across services via a propagated trace ID). Together they let you detect a problem, localize it, and see the detail.

The design decisions are where telemetry is emitted, how it's shipped off-host without adding latency, how much you sample high-volume data to control cost, and what you alert on, symptoms and user impact (error rate, latency) over raw resource metrics. OpenTelemetry is the vendor-neutral standard. Observability isn't an afterthought; a system you can't see into can't be operated.

These three pull against each other, so you decide per data type rather than globally. Strong consistency needs cross-replica coordination, which adds latency and cost; low latency pushes you toward caches and edge replicas, which weakens consistency; and cutting cost often means fewer replicas or cheaper storage, which hits one of the other two.

The senior approach classifies data: money and inventory get strong consistency and eat the latency, feeds and counts get eventual consistency for speed and cheap scale, and you cache the read-heavy, slow-changing data hard. Stating these choices explicitly, and why, is exactly what the interview measures, because there's no single right architecture, only the right trade for each requirement.

Start from access patterns and requirements, not familiarity. Ask: what are the read and write patterns, what consistency does the data need, what scale and query shapes, and is the schema stable. Then match: relational for transactions, joins, and integrity; document for flexible, self-contained records; key-value for simple fast lookups; wide-column for huge write-heavy time-series or feed data; graph for relationship-heavy queries; search engines for full-text.

In a real system you often use several, one per service's needs (polyglot persistence), rather than forcing everything into one store. The reasoning you show matters more than the specific pick: The access pattern, name the consistency need, then justify the store. 'I'd use X because the workload is write-heavy and append-only' beats naming a trendy database.

Per-server counters don't work, because a client hitting different servers could exceed the global limit. The counter state must be shared, so you keep it in a fast central store like Redis, keyed by client, and every server increments and checks the same counter, usually with an atomic operation or a small Lua script to avoid race conditions.

The trade-off is that the central store adds latency and is a dependency, so you handle its failure (fail open to stay available, or fail closed to stay protected, a deliberate choice) and sometimes accept slightly loose limits by batching counter updates. Sliding-window-log is accurate but memory-heavy; sliding-window-counter approximates it cheaply. Sticky routing plus per-server limits is a lighter but less exact alternative.

Design for change rather than predicting the final shape. Keep clear boundaries and interfaces between parts so you can replace one without touching the rest, start simple (a monolith with clean modules) and extract services only when a specific pain (scaling, team ownership, deploy coupling) justifies the cost, and put a queue or API boundary where you expect future async or a service split.

The strangler pattern is the practical migration path: build the new component alongside the old, route a slice of traffic to it, and gradually shift over while both run, instead of a risky big-bang rewrite. The senior instinct is that architecture is incremental, you earn complexity when the requirements demand it, and premature microservices or premature sharding are as costly as adding them too late.