Top 50 System Design Interview Questions with Answers (2026): Junior Engineer to Architect

💡 Why Interviewers Ask This: The baseline definition. It establishes your mindset: you are transitioning from writing single-file algorithms to building global infrastructure.

DNS is the "phonebook of the internet." When a user types a URL, the browser queries a DNS resolver, which traverses the Root Nameserver → TLD Nameserver → Authoritative Nameserver to translate the human-readable domain (google.com) into a machine-readable IP address (142.250.190.46).

💡 Why Interviewers Ask This: DNS is the very first step in any web request. Understanding DNS routing and DNS-level load balancing (like AWS Route 53) is mandatory for global architecture.

TCP (Transmission Control Protocol) is connection-oriented, ensuring reliable, ordered, and error-checked delivery of packets — used for HTTPS and file transfers. UDP (User Datagram Protocol) is connectionless, prioritizing high-speed transmission over reliability — used for video streaming, VoIP, and gaming.

💡 Why Interviewers Ask This: Tests foundational networking knowledge to ensure you choose the right transport protocol for different system requirements.

A Reverse Proxy (like Nginx or HAProxy) sits in front of web servers and intercepts incoming client requests. It provides load balancing, SSL termination, caching, and DDoS protection, hiding the internal server IP addresses from the public internet.

💡 Why Interviewers Ask This: You cannot design a secure, scalable backend without a reverse proxy. It separates the public internet from your internal private network.

A CDN is a geographically distributed network of proxy servers that caches static assets (images, videos, HTML, CSS) at Edge Locations closest to the end user. This drastically reduces network latency, lowers bandwidth costs, and shields the origin server from traffic spikes.

💡 Why Interviewers Ask This: CDN implementation is the standard immediate answer to "How do we reduce latency for global users fetching images?"

Latency is the time for a single data packet to travel from source to destination (measured in milliseconds). Throughput is the total volume of data that can be processed within a given timeframe (measured in requests per second or Mbps). You can have high throughput but terrible latency — like shipping a hard drive full of data via FedEx.

💡 Why Interviewers Ask This: A crucial system trade-off — always discuss both dimensions when evaluating architectural choices.

IPv4 uses a 32-bit address space (~4.3 billion addresses) which have been exhausted. IPv6 uses a 128-bit address space, providing a virtually infinite number of addresses along with improved routing efficiency and native IPSec security.

💡 Why Interviewers Ask This: Shows basic network literacy and understanding of internet scaling constraints.

REST uses standard HTTP methods and URL endpoints — can over-fetch or under-fetch data. GraphQL uses a single endpoint allowing clients to query exactly the data shape they need. gRPC uses HTTP/2 and Protocol Buffers for highly compressed, binary, bi-directional communication — ideal for internal microservices.

💡 Why Interviewers Ask This: Tests API design skills. The choice of communication protocol dictates the efficiency of your system's data transfer.

A Webhook is a user-defined HTTP callback. Instead of a client continuously polling a server, the server proactively pushes real-time data via an HTTP POST request to the client's registered URL the moment an event occurs — e.g., a Stripe payment confirmation.

💡 Why Interviewers Ask This: Tests your knowledge of event-driven architecture and avoiding resource-heavy polling mechanisms.

An API Gateway acts as the single point of entry into a microservices architecture. It handles cross-cutting concerns like request routing, rate limiting, authentication, payload transformation, and analytics, abstracting the complexity of the backend from the client.

💡 Why Interviewers Ask This: The standard architectural pattern for modern cloud environments like AWS API Gateway.

Vertical Scaling (Scaling Up): upgrading a single machine with a faster CPU, more RAM, or larger disks — limited by hardware, causes downtime. Horizontal Scaling (Scaling Out): adding more standard machines to a resource pool — theoretically infinite scale, highly fault-tolerant.

💡 Why Interviewers Ask This: The cornerstone of system design. Modern systems default to horizontal scaling to survive massive traffic.

A Load Balancer efficiently distributes incoming network traffic across a group of backend servers. It ensures high availability, prevents any single server from becoming a bottleneck, and performs health checks to reroute traffic around failed nodes.

💡 Why Interviewers Ask This: Load balancers are mandatory for horizontal scaling. You cannot build a distributed system without them.

Round Robin: distributes requests sequentially. Least Connections: sends traffic to the server with the fewest active connections. IP Hash: uses the client's IP to consistently route them to the same server — useful for sticky sessions.

💡 Why Interviewers Ask This: Tests your ability to match the routing strategy to the specific workload profile of the application.

Standard hashing (hash(key) % N) breaks catastrophically if the server count changes, requiring massive data reallocation. Consistent Hashing places servers and keys on a conceptual circular hash ring — when a server is added/removed, only k/N keys need to move to the adjacent node.

💡 Why Interviewers Ask This: The most frequently asked algorithm in FAANG system design interviews. It powers DynamoDB, Cassandra, and Redis clusters.

Caching stores copies of frequently accessed, expensive-to-compute data in a high-speed, temporary storage layer (usually RAM, like Redis or Memcached). Future requests for that data are served significantly faster than querying the primary database.

💡 Why Interviewers Ask This: Caching is the #1 tool for drastically reducing latency and database load.

LRU (Least Recently Used): evicts the item not accessed for the longest time — best for recency-based workloads. LFU (Least Frequently Used): evicts the item accessed the fewest total times — best for overall popularity workloads.

💡 Why Interviewers Ask This: Caches have finite memory. You must know how to intelligently discard old data to make room for new data.

Write-Through: data is written to cache and database simultaneously — safe, but slower writes. Write-Around: data is written directly to database, bypassing cache — prevents cache flooding. Write-Back: data is written only to cache and acknowledged immediately, asynchronously flushed to DB — blazing fast but risks data loss on cache crash.

💡 Why Interviewers Ask This: Evaluates your ability to balance data consistency against write latency.

When a popular cached item suddenly expires, thousands of concurrent requests all simultaneously experience a cache miss and directly hit the underlying database — potentially crashing it. Solutions: request coalescing (only one request rebuilds the cache) and probabilistic early expiration.

💡 Why Interviewers Ask This: Proves you understand how systems fail at scale. A well-designed caching strategy prevents catastrophic database overload.

Both are in-memory key-value stores. Memcached is simple, multi-threaded, and purely for volatile caching. Redis supports advanced data structures (Lists, Sets, Sorted Sets), persistence to disk, pub/sub messaging, and high-availability clustering — making it the industry standard.

💡 Why Interviewers Ask This: Redis usually wins. You must know exactly why it beats Memcached in modern architectures.

A load-balancing technique where a client's requests are continuously routed to the exact same backend server for their session duration. It is generally an anti-pattern in modern design because it hinders auto-scaling and causes uneven load distribution. The correct solution: move session state to an external distributed cache like Redis.

💡 Why Interviewers Ask This: Tests your knowledge of state management. Statelessness is the prerequisite for horizontal scalability.

SQL databases (PostgreSQL, MySQL) use rigid table schemas, prioritize ACID compliance, and scale vertically. NoSQL databases (MongoDB, Cassandra) use flexible schemas (Documents, Key-Value, Wide-Column), prioritize eventual consistency, and are designed for massive horizontal scaling.

💡 Why Interviewers Ask This: The most important database decision you will make. You must justify your DB choice based on the data structure and scale.

ACID guarantees transaction reliability: Atomicity (all operations succeed or all fail), Consistency (data moves between valid states), Isolation (concurrent transactions do not interfere), Durability (committed transactions survive power failures).

💡 Why Interviewers Ask This: The bedrock of financial systems. You cannot design a payment gateway without strict ACID compliance.

BASE is the antithesis of ACID, prioritizing availability: Basically Available (system guarantees a response, even if stale), Soft State (system state may change without input due to eventual consistency), Eventually Consistent (all nodes converge to the same data given time).

💡 Why Interviewers Ask This: Proves you understand the trade-offs made by high-throughput systems like social media feeds.

The CAP Theorem states a distributed data store can only guarantee two of three simultaneously: Consistency (all nodes see the exact same data), Availability (every request gets a response), and Partition Tolerance (system survives network drops). Because partitions are inevitable, designers must choose between CP or AP.

💡 Why Interviewers Ask This: The absolute golden rule of distributed system design.

Partitioning divides a large table into logical pieces within the same database instance. Sharding is a specific type of horizontal partitioning where data is physically distributed across multiple distinct database servers based on a Shard Key (e.g., User ID) — mandatory for systems holding petabytes of data.

💡 Why Interviewers Ask This: Choosing the wrong shard key results in "hot partitions" with uneven load — a critical design mistake.

An index is an internal data structure (usually a B-Tree or Hash Table) holding a sorted copy of specific columns with pointers to the actual disk rows. It drastically speeds up SELECT reads at the cost of slowing down INSERT/UPDATE writes and consuming extra disk space.

💡 Why Interviewers Ask This: You must understand database performance tuning. Over-indexing ruins write performance.

Master-Slave (Leader-Follower): only the Master accepts writes; Slaves serve reads — easy to manage but Master is a write bottleneck. Multi-Master: any node can accept writes and sync with others — scales writes infinitely but introduces complex data conflict resolution issues.

💡 Why Interviewers Ask This: Tests your ability to architect for heavy-read vs. heavy-write workloads.

Strong Consistency: after a write, any subsequent read from any node instantly returns the updated value — high latency. Eventual Consistency: nodes may be temporarily out-of-sync but will converge to the same value — high availability, low latency.

💡 Why Interviewers Ask This: Focuses heavily on UX. Would you rather a post load instantly (Eventual) or wait 5 seconds for absolute accuracy (Strong)?

A highly space-efficient probabilistic data structure testing set membership. It can definitively tell you if an item is "not in the set" (zero false negatives), but can only say "possibly in the set" (allows false positives). Used by databases to quickly avoid expensive disk lookups for non-existent records.

💡 Why Interviewers Ask This: Advanced memory optimization — a must-know for high-performance database internals.

B-Trees (used by PostgreSQL) update data in-place on disk — excellent for heavy-read workloads. LSM Trees (Log-Structured Merge Trees), used by Cassandra, append data sequentially in memory and flush to immutable disk files — exceptionally fast for extremely heavy write workloads.

💡 Why Interviewers Ask This: A senior-level database internals question that separates framework users from true systems architects.

A Monolith tightly couples all business domains into one deployable codebase — easy to debug, but hard to scale teams. Microservices decouple domains into independently deployable services communicating over network APIs — scales teams and infrastructure flawlessly, but introduces immense operational and network complexity.

💡 Why Interviewers Ask This: You must articulate that Microservices are an organizational scaling solution, not a silver bullet.

In a microservices environment, IPs change dynamically as containers scale. Service Discovery (via Consul or ZooKeeper) acts as a dynamic registry — services query it to find the current, active IP address of the service they need to communicate with.

💡 Why Interviewers Ask This: Essential for Kubernetes and containerized cloud environments where server IPs are ephemeral.

RabbitMQ: messages are pushed to queues, consumed by a single worker, then deleted — Point-to-Point. Kafka: messages are appended to an immutable distributed log; multiple consumers can independently read and replay the stream at their own pace — ideal for event sourcing and fan-out.

💡 Why Interviewers Ask This: Tests your ability to architect asynchronous, event-driven systems correctly based on data retention and fan-out requirements.

Message brokers guarantee delivery types: At-Most-Once (might lose data), At-Least-Once (might duplicate data), and Exactly-Once (data arrives exactly one time). Truly guaranteeing exactly-once at the network layer is near-impossible — the correct solution is implementing idempotency at the application layer to safely deduplicate.

💡 Why Interviewers Ask This: A trap question — proves you know the practical solution is consumer-side idempotency.

A DLQ is a specialized queue where messages are routed if they cannot be processed successfully after a certain number of retries (due to malformed payloads or persistent downstream failures). It prevents "poison pill" messages from endlessly blocking the main queue.

💡 Why Interviewers Ask This: Proves you know how to build robust, fault-tolerant asynchronous systems that don't crash when faced with bad data.

Token Bucket: tokens are added to a bucket at a fixed rate; requests consume tokens — allows sudden short bursts. Leaky Bucket: requests enter a queue and are processed at a strict constant rate — smooths traffic into a steady stream, strictly forbidding bursts.

💡 Why Interviewers Ask This: API defense architecture. You must know how to protect backend services from DDoS or abusive clients.

If a downstream microservice repeatedly fails or times out, the circuit "trips" and fails fast, returning a default fallback response without attempting further calls. This prevents cascading system failures and gives the broken service time to recover.

💡 Why Interviewers Ask This: A critical resiliency pattern — shows you understand how to protect a network from being overwhelmed by infinite retries.

Because microservices do not share a database, standard ACID transactions are impossible. A Saga breaks a distributed transaction into a sequence of local transactions. If a step fails, it automatically executes Compensating Transactions to undo preceding steps — e.g., booking Uber: charge card → assign driver; if driver fails → refund card.

💡 Why Interviewers Ask This: The industry standard for handling distributed data integrity across microservice boundaries.

Instead of storing just the current state, Event Sourcing stores a sequence of immutable, state-changing events. The current state is derived by replaying the event log from the beginning. It provides a perfect, unalterable audit trail — widely used in financial ledgers and banking applications.

💡 Why Interviewers Ask This: Widely used in fintech and audit-critical systems.

CQRS strictly separates the models used to update data (Commands) from the models used to read data (Queries). This allows the read and write databases to be scaled, optimized, and sharded completely independently.

💡 Why Interviewers Ask This: Often paired with Event Sourcing, it is the ultimate architectural pattern for high-performance, read-heavy enterprise systems.

Map long URLs to a 7-character Base62 encoded string. Use a NoSQL Key-Value store (DynamoDB) for O(1) lookups. Generate unique IDs using a Key Generation Service (KGS) or ZooKeeper to prevent collisions. Heavily cache popular links (Redis) and use an API Gateway with rate limiting.

💡 Why Interviewers Ask This: The classic System Design 101 question. Tests encoding logic, hashing, and read-heavy caching architecture.

Clients maintain persistent WebSocket connections to Chat Servers. A Session Service (Redis) tracks which user is connected to which Chat Server. When User A messages User B, the request hits a message queue, checks the Session Service, and pushes the message to User B's WebSocket. Use Cassandra for high-write message history storage.

💡 Why Interviewers Ask This: Tests real-time communication, connection management, and asynchronous message routing.

Relying on a single auto-incrementing SQL DB creates a write bottleneck. Snowflake ID generates a 64-bit integer combining a Timestamp + Datacenter/Machine ID + Local Sequence Number — producing sortable, completely unique IDs across all nodes without any central coordination.

💡 Why Interviewers Ask This: Crucial for horizontally sharded databases where multiple nodes must generate primary keys concurrently without collision.

Store original video in Object Storage (S3). Asynchronously trigger a transcoding pipeline to encode video into multiple resolutions (HLS/DASH). Push transcoded chunks to a global CDN. The client player dynamically adjusts requested resolution based on the user's real-time internet bandwidth (Adaptive Bitrate Streaming).

💡 Why Interviewers Ask This: Tests knowledge of heavy asset storage, asynchronous processing queues, and Edge/CDN delivery networks.

In a distributed system, multiple nodes might try to modify a shared resource concurrently. A distributed lock ensures only one node succeeds. Implemented using ZooKeeper, or via Redis using the Redlock algorithm (setting a key with an expiration TTL to automatically release if the holder crashes).

💡 Why Interviewers Ask This: Tests advanced concurrency and preventing race conditions across physical machine boundaries.

Standard SQL coordinate queries require full table scans. Use spatial indexing: Geohash (converting 2D coordinates into a 1D alphanumeric string for rapid string prefix matching) or a QuadTree (recursively dividing a map into 4 quadrants for fast nearest-neighbor queries).

💡 Why Interviewers Ask This: Proves you know specialized data structures required for geospatial architecture.

A SPOF is a system component that, if it fails, stops the entire system from working. Mitigated through Redundancy (deploying multiple instances of databases, load balancers, and network links) and removing all centralized bottlenecks.

💡 Why Interviewers Ask This: High availability (99.999% uptime — "five nines") is impossible if a single server crash takes down the app.

Active-Passive: one region handles all traffic; if it goes down, DNS routes to a standby region — cheaper, but has downtime during failover. Active-Active: multiple global regions handle traffic simultaneously via Geo-DNS — zero downtime, but requires incredibly complex bidirectional database replication.

💡 Why Interviewers Ask This: Tests your understanding of global disaster recovery and the cost vs. reliability trade-off.

Quick math to estimate a system's required storage, bandwidth, and throughput. Example: "100M Daily Active Users × 2 reads/day = 200M requests ÷ 86,400 seconds ≈ 2,300 Requests Per Second (RPS)." System constraints dictate design decisions.

💡 Why Interviewers Ask This: System constraints dictate design. You cannot build a database schema until you mathematically prove how much data it needs to hold.

Implement it at the API Gateway level. Use Redis for fast in-memory counter tracking. Apply the Sliding Window Log or Token Bucket algorithm. If a user's IP or API Key exceeds the threshold, return HTTP 429 "Too Many Requests".

💡 Why Interviewers Ask This: A very common, self-contained system design question that perfectly blends algorithms (Token Bucket), infrastructure (Redis), and HTTP protocols (429).