System Design Interview Questions
• Images marked with ★ are AI-generated.
What is CAP Theorem?
The CAP theorem states that a distributed system cannot simultaneously guarantee all three properties: Consistency, Availability, and Partition Tolerance. It can only guarantee at most two of these at the same time.
Consistency (C): After an operation, all nodes see the same data, so queries return the same result.
Availability (A): The system remains operational and responsive without downtime.
Partition Tolerance (P): The system continues functioning despite network communication failures between nodes.
Database Trade-offs:
This trade-off helps understand the design choices behind different distributed database systems.

How do NoSQL databases differ from SQL databases?
SQL:
Model
Data
Flexibility
Transactions
NoSQL:
Model
Data
Flexibility
Transactions

How would you design a global chat service like WhatsApp or Facebook Messenger?
Required Features
Common Problems
Possible Tips for Consideration
How would you design a URL shortening service like TinyURL or bit.ly?
TinyURL or bit.ly takes a long URL and generates a new unique short URL. These systems are also capable of taking the shortened URL and returning the original full URL.
Required Features
Common Problems
Possible Tips for Consideration
How would you design a global file storage and sharing service like Google Drive or Dropbox?
Required Features
Common Problems
Possible Tips for Consideration
How would you design a ride-sharing system like Uber, Ola, or Lyft?
These platforms help users request rides and drivers pick them up from the requested location and drop them at the selected destination.
Required Features
Common Problems
Possible Tips for Consideration
What advantages does normalization offer when creating a database schema?
Normalization organizes database tables to minimize redundancy and enhance data consistency. It structures data efficiently, making the database easier to manage and maintain. Key benefits include eliminating duplicate data, improving data integrity, and ensuring more dependable updates, inserts, and deletions. For example, instead of repeating customer information in every order, normalization stores Customers and Orders in separate tables linked by a customer ID, preventing data duplication.
How can you design a secure authentication and authorization system for a distributed application?
A secure authentication and authorization system verifies user identities and manages access to resources across distributed services effectively. It integrates strong identity management, token-based authentication, and detailed access control. This includes using protocols like OAuth 2.0, JWT, multi-factor authentication (MFA), and password hashing for secure identity verification. Authorization is managed through role-based (RBAC) or attribute-based access control (ABAC) with centralized identity providers and token validation across services. For instance, in a microservices setup, a user logs in through an identity provider, obtains a JWT token, and each service checks the token before granting access based on assigned roles such as admin or user.
How do you choose between Monolithic and Microservices architectures in High-Level Design (HLD)?
The decision between Monolithic and Microservices architectures depends on factors such as the application's size, scalability needs, complexity, and team organization. Monolithic architecture fits smaller, simpler applications, while microservices suit large-scale, highly scalable systems. Monoliths are easier to develop and deploy initially but can become challenging to scale and maintain as complexity grows. Microservices offer independent scalability and flexibility but add operational and communication overhead. For example, startups often start with monolithic designs for quick development, whereas companies like Netflix and Amazon adopt microservices to scale services independently.
Rule of thumb: Begin with a monolithic approach for small systems, then refactor to microservices as the system expands.
What are the trade-offs between Relational and Non-Relational (NoSQL) databases in High-Level Design?
Choosing between Relational and NoSQL databases depends on data structure, scalability, consistency requirements, and workload types. Relational databases excel with structured data, strong consistency, and support for complex queries, while NoSQL databases provide flexible schemas, horizontal scalability, and high performance for large distributed systems. For example, banking systems rely on relational databases like MySQL or PostgreSQL for transactional accuracy, whereas social media platforms use NoSQL databases such as MongoDB or Cassandra to manage huge volumes of unstructured data and high traffic.
How do you ensure high availability in a High-Level Design?
High availability means keeping a system operational and accessible despite failures or heavy loads. It is achieved by removing single points of failure and building redundancy, failover, and distributed infrastructure. Techniques include replication, load balancing, failover mechanisms, continuous monitoring, and disaster recovery planning. For instance, a cloud application uses load balancers to distribute traffic across multiple servers, automatically redirecting requests if one server fails, thus maintaining uninterrupted service.
What is load balancing, and why is it important in High-Level Design?
Load balancing distributes incoming network or application traffic across multiple servers to optimize resource use, ensure high availability, and enhance system performance. It prevents any single server from being overwhelmed, improving scalability and fault tolerance. For example, a web application might use a load balancer like Nginx or AWS ELB to evenly distribute user requests among several servers, ensuring efficient handling of peak traffic without downtime.
What are the essential considerations for designing a scalable system in High-Level Design?
Designing a scalable system involves ensuring the application can handle increasing users, traffic, and data without losing performance. This requires workload distribution, resource optimization, and bottleneck reduction. Common techniques include horizontal scaling, caching, data partitioning, and database replication. Performance and reliability can also be enhanced with asynchronous processing and distributed infrastructure. For example, a video streaming service employs CDNs for static content, Redis for caching, and multiple servers behind a load balancer to support millions of concurrent viewers.
What is the purpose of database indexing?
Database indexing is a method used to speed up data retrieval by creating a structured reference to the data within a table. Indexes allow the database to quickly find records without scanning the entire table. This significantly enhances query performance and reduces retrieval time. However, indexing requires additional storage and can slightly slow down insert or update operations. For example, in a banking system, an index on the account number field enables quick access to customer accounts during transactions.
How can data consistency be maintained across distributed systems in High-Level Design?
Data consistency in distributed systems ensures that all nodes or services have synchronized and accurate data, even with concurrent operations. The chosen consistency model depends on business needs, scalability, and availability. Techniques include distributed transactions, idempotent operations, and conflict resolution. Systems may opt for strong consistency or eventual consistency based on the CAP theorem trade-offs. For example, online banking uses strong consistency to keep account balances accurate, whereas social media feeds use eventual consistency for better scalability.
What is the importance of fault tolerance in High-Level Design?
Fault tolerance ensures a system continues operating correctly even if some components fail or become unavailable. It enhances reliability by reducing downtime and preventing widespread failures. This is achieved through redundancy, replication, and isolating failures. Fault tolerance also improves user experience via graceful degradation and recovery processes. For instance, in a microservices application, if the recommendation service fails, the core application keeps running by temporarily disabling recommendations rather than crashing completely.
How do you incorporate disaster recovery in High-Level Design?
Disaster recovery in HLD aims to enable quick system recovery and continued operation after major incidents such as server failures, data loss, or regional outages. It involves backup procedures, data replication, failover mechanisms, and recovery planning to minimize downtime and data loss. Strategies include geo-replication, automated failovers, and defining recovery metrics like RPO (Recovery Point Objective) and RTO (Recovery Time Objective). For example, a cloud app replicates its database across multiple regions so that if one data center fails, traffic redirects to another region with minimal disruption.
What is Event-Driven Architecture and how is it applied in High-Level Design?
Event-Driven Architecture (EDA) is a design pattern where components interact by producing and consuming events asynchronously, rather than through direct synchronous calls. Producers create events that are sent to an event broker or message queue, and consumers process these events independently. This approach decouples components, enhancing scalability, resilience, and flexibility. For example, in an e-commerce platform, placing an order triggers an event published to Kafka or RabbitMQ, which various services like payment, inventory, and notifications consume to perform their functions.
How does a cache determine when it is full and which data to evict?
A cache constantly monitors its memory usage as data is added, updated, or removed. Each cache entry has a size, and the cache manager tracks the total memory consumed. When new data is inserted, the cache calculates its size and adds it to current usage. If this total exceeds the cache’s configured limit, an eviction policy such as Least Recently Used (LRU) or Least Frequently Used (LFU) is triggered to free up space. For example, if a Redis cache with a 1 GB limit is using 950 MB and a new 100 MB object is added, Redis will evict older or less-used entries until usage falls below 1 GB.
What are the key principles of RESTful API design in High-Level Design?
RESTful API design follows architectural guidelines that promote scalable, standardized, and maintainable communication between clients and servers. It emphasizes resource-based communication, stateless interactions, and adherence to HTTP standards. This includes using resource-oriented URIs, standard HTTP methods (GET, POST, DELETE, etc.), and status codes for clear, consistent communication. Scalability and maintainability are supported through statelessness, versioning, and content negotiation. For example, a user management API might have endpoints like GET /users/1, POST /users, and DELETE /users/1, treating users as distinct resources with appropriate HTTP methods.
What is the function of a message broker in High-Level Design? Provide examples.
A message broker is middleware that facilitates asynchronous communication between services by receiving, storing, and forwarding messages. It decouples system components, enhancing scalability, reliability, and fault tolerance in distributed architectures. Message brokers enable loose coupling by buffering messages and managing their delivery. For example, in an e-commerce system, when an order is placed, a message broker such as Kafka or RabbitMQ sends events to inventory, payment, and notification services independently, eliminating the need for direct service-to-service calls.
What is database replication, and why is it important?
Database replication involves copying and synchronizing data across multiple database servers to boost availability, reliability, and performance. It ensures that the system remains operational even if a database server fails. Replication improves fault tolerance by maintaining multiple data copies and enhances read scalability by distributing read queries among replicas. For instance, in an e-commerce platform, the primary database handles write operations, while replica databases serve read requests such as product searches and order histories.
What is a distributed cache in High-Level Design, and what benefits does it offer?
A distributed cache stores cached data across multiple servers or nodes rather than a single machine, enabling faster and scalable data access in distributed systems. It reduces database load and boosts application performance by serving frequently requested data from memory.
Key Benefits:
Performance: Serves frequently requested data from memory, significantly reducing response times.
Scalability: Spreads cached data across nodes, allowing the system to handle higher loads efficiently.
Fault Tolerance: Provides resilience through cache replication across multiple nodes.
Reduced Database Load: Offloads repetitive read queries from the primary database.
For example, an e-commerce platform might use a distributed cache like Redis Cluster to store popular product details, ensuring rapid responses even during peak traffic.
How does the CAP theorem influence the design of distributed databases?
The CAP theorem states that a distributed system can guarantee only two of the following three properties simultaneously: Consistency, Availability, and Partition Tolerance. This principle guides architects in balancing trade-offs based on business priorities and system needs.
CP Systems (Consistency + Partition Tolerance):
AP Systems (Availability + Partition Tolerance):
The choice depends on whether strict data consistency or continuous availability is more critical for the business use case.
What distinguishes Horizontal Scaling from Vertical Scaling?
Scaling increases a system's capacity to handle more traffic, users, or workload. The two primary approaches differ in how they achieve this growth.
Horizontal Scaling (Scale Out):
Vertical Scaling (Scale Up):
Rule of thumb: Vertical scaling works well for smaller systems, but horizontal scaling is preferred for large-scale distributed applications.
What is Rate Limiting and why is it important?
Rate limiting controls the number of requests a client can make to a server within a defined time frame. It is a critical mechanism for protecting systems from abuse and maintaining stability.
Why it matters:
Security: Protects against denial-of-service (DoS) attacks and brute-force attempts by blocking excessive requests.
Fair Resource Allocation: Ensures no single user monopolizes server resources, keeping the system fair for all clients.
System Stability: Prevents server overload during traffic spikes, maintaining consistent performance.
Common Algorithms:
For example, a public API might restrict users to 100 requests per minute to avoid misuse and sustain performance. HTTP status code 429 (Too Many Requests) is returned when the limit is exceeded.
What do latency, throughput, and availability mean in system design?
Latency, throughput, and availability are the three core metrics for assessing system performance and reliability.
Latency:
Throughput:
Availability:
These three metrics often involve trade-offs and must be balanced based on the system's requirements.
How do sharding and database partitioning differ?
Both sharding and partitioning split large datasets into smaller parts for better performance and manageability, but they differ in scope and distribution.
Partitioning:
Sharding:
Key Difference: Partitioning is an internal database optimization, while sharding is a distributed architecture strategy. Sharding introduces additional complexity around cross-shard queries and data rebalancing.
What is caching and what are the different cache update strategies in system design?
Caching temporarily stores frequently accessed data in fast memory to speed up future requests, reducing response time and server load.
Common Cache Update Strategies:
Write-Through:
Write-Back (Write-Behind):
Cache-Aside (Lazy Loading):
Write-Around:
Strategy choice depends on consistency requirements, read/write patterns, and performance goals. For example, an e-commerce site might cache popular product info using Write-Through for consistency or Cache-Aside for flexibility.
What is a Content Delivery Network (CDN) and how does it work in system design?
A Content Delivery Network (CDN) is a globally distributed network of servers that caches and delivers content from locations geographically closer to the end user.
How it works:
1. Static assets (images, videos, scripts, files) are cached on edge servers distributed around the world.
2. When a user requests content, the CDN routes the request to the nearest edge server rather than the origin server.
3. If the edge server has the content cached, it serves it directly (cache hit); otherwise, it fetches from the origin and caches it for future requests (cache miss).
Key Benefits:
For example, when streaming a video, a CDN delivers content from the nearest edge server, resulting in faster playback and reduced buffering.
How do message queues such as Kafka and RabbitMQ enhance system design?
Message queues like Kafka and RabbitMQ facilitate asynchronous communication between different services or components, enabling them to exchange data without direct dependencies. This decoupling allows systems to process tasks more efficiently and handle large request volumes smoothly.
Key Benefits:
Decoupling: Services operate independently without tight dependencies on each other.
Scalability: Buffers messages during traffic spikes, preventing bottlenecks and allowing services to scale independently.
Reliability: Messages are persisted in the queue, ensuring delivery even if a service is temporarily unavailable.
Kafka vs RabbitMQ:
For example, in a food delivery app, once an order is placed, a message queue distributes events independently to payment, notification, and delivery services, allowing each to process tasks without slowing down the main application.
What are the differences between synchronous and asynchronous communication in distributed systems?
In distributed systems, the communication style between services has a significant impact on performance, scalability, and resilience.
Synchronous Communication:
Asynchronous Communication:
When to use which:
How would you design an API Gateway?
An API Gateway serves as a single entry point for all client requests in a microservices architecture. It routes incoming requests to the appropriate backend services and manages cross-cutting concerns centrally.
Core Responsibilities:
Request Routing: Directs requests to the correct microservice based on the URL path or headers.
Authentication & Authorization: Validates JWT tokens or API keys before forwarding requests to services.
Rate Limiting: Enforces per-client request limits to protect backend services from abuse.
Load Balancing: Distributes traffic across multiple instances of a service.
Request Aggregation: Combines responses from multiple services into a single response for the client.
Logging & Monitoring: Centralized observability for all incoming traffic.
Popular Tools: AWS API Gateway, Kong, Nginx, Apigee.
For example, in an e-commerce platform, the API Gateway handles requests from mobile and web apps, routing them to User, Product, and Payment services — while enforcing rate limits and validating tokens at a single layer.
What is the Circuit Breaker Pattern?
The Circuit Breaker Pattern is a fault-tolerance strategy used to prevent repeated calls to failing services in distributed systems. It enhances system resilience by stopping cascading failures during outages and allowing graceful recovery.
How it works — three states:
Closed (Normal): Requests flow through normally. Failures are counted.
Open (Tripped): After a failure threshold is exceeded, the circuit "opens" and all requests are immediately rejected or given a fallback response — no calls reach the failing service.
Half-Open (Recovery): After a timeout, a limited number of test requests are allowed through. If they succeed, the circuit closes again; if they fail, it reopens.
Benefits:
For example, if the payment service in a microservices app becomes unavailable, the circuit breaker stops further calls to it, returning a graceful error message instead of causing a system-wide failure.
What is Consistent Hashing?
Consistent hashing is a distributed hashing technique that evenly distributes data across multiple servers while minimizing data movement when servers are added or removed. It is widely used in distributed caching and database sharding.
How it works:
Why it matters:
Virtual Nodes: To improve balance, each server is assigned multiple virtual positions on the ring.
For example, Redis Cluster uses consistent hashing to efficiently distribute cached data across many nodes, ensuring minimal disruption when the cluster scales.
What is Service Discovery?
Service discovery is a mechanism in microservices architectures that allows services to dynamically locate and communicate with each other without relying on hardcoded network addresses. As service instances scale up or down, their addresses change — service discovery automates this tracking.
Two main approaches:
Client-Side Discovery:
Server-Side Discovery:
Popular Tools:
For example, Kubernetes uses internal DNS and service registries to enable services to find one another automatically as pods scale in and out.
What is a Reverse Proxy?
A reverse proxy is a server that sits in front of backend servers, accepting client requests and forwarding them on the backend's behalf. Unlike a forward proxy (which acts for clients), a reverse proxy acts for servers.
Key Functions:
Load Balancing: Distributes incoming traffic across multiple backend servers to prevent overload.
Security: Hides backend server details (IPs, topology) from clients, reducing the attack surface.
Caching: Caches responses for static content, reducing load on backend servers.
SSL Termination: Handles HTTPS encryption/decryption, offloading this work from backend services.
Request Routing: Routes requests to different services based on URL paths or headers.
Popular Tools: Nginx, HAProxy, AWS CloudFront, Cloudflare.
For example, Nginx functions as a reverse proxy by accepting user requests and directing them to multiple application servers behind it, while also caching static assets and handling SSL.
What distinguishes ACID from BASE in database systems?
ACID and BASE represent two contrasting consistency models used in database systems, each suited to different use cases.
ACID (Atomicity, Consistency, Isolation, Durability):
BASE (Basically Available, Soft-state, Eventually Consistent):
For example, banking systems use ACID-compliant databases like PostgreSQL for precise transactions, whereas social media platforms rely on BASE databases like Cassandra for scalability.

What is the difference between High-Level Design (HLD) and Low-Level Design (LLD)?
HLD and LLD represent two distinct phases of system design, each operating at a different level of abstraction.
HLD (High-Level Design):
LLD (Low-Level Design):
In practice:
For instance, in a food delivery app, HLD might define the User Service, Order Service, and Payment Service and their interactions — while LLD designs the specific classes like `User`, `Order`, and `PaymentProcessor` with their methods and attributes.

How do Stateful and Stateless systems differ?
Stateful and Stateless systems differ in how they handle client session data between requests, which has major implications for scalability and architecture.
Stateful Systems:
Stateless Systems:
Common pattern: REST APIs using JWT tokens are stateless — the token carries all required user context with every request, eliminating server-side session storage.
For example, traditional web login sessions are stateful (server stores session), whereas REST APIs using JWT tokens are stateless (token carries the session).

What is the OSI Model?
The OSI (Open Systems Interconnection) Model is a conceptual framework that standardizes network communication by dividing it into seven distinct layers, each responsible for specific functions. This separation aids in troubleshooting and enables modular, interoperable networking design.
The 7 Layers (top to bottom):
7 - Application: User-facing protocols — HTTP, HTTPS, FTP, DNS, SMTP.
6 - Presentation: Data translation, encryption, and compression (e.g., SSL/TLS, JPEG).
5 - Session: Manages sessions and connections between applications.
4 - Transport: End-to-end communication, reliability, flow control — TCP, UDP.
3 - Network: Logical addressing and routing — IP, ICMP, routers.
2 - Data Link: Physical addressing (MAC), error detection — Ethernet, switches.
1 - Physical: Raw bit transmission over physical media — cables, fiber, radio signals.
Why it matters in system design:
For example, when a user accesses a website, data travels from the Application Layer (HTTP request) down through all layers to the Physical Layer for transmission, then back up on the receiving end.
What is the difference between HTTP and HTTPS?
HTTP (HyperText Transfer Protocol) and HTTPS (HyperText Transfer Protocol Secure) are both protocols for transferring data over the internet, but they differ significantly in security.
HTTP:
HTTPS:
How HTTPS works:
1. Client and server perform an SSL/TLS handshake to establish a secure connection.
2. A digital certificate verifies the server's identity.
3. All subsequent data is encrypted before transmission.
For example, an online banking site uses HTTPS to protect user credentials and payment details during transmission, while a simple blog might use HTTP for public content.

How do TCP and UDP differ?
TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two core transport layer protocols, each designed for different use cases.
TCP:
UDP:
For example, banking websites use TCP for reliability and accuracy, whereas live video streams use UDP for faster, low-latency transmission where occasional packet loss is acceptable.

What is DNS and why is it important?
DNS (Domain Name System) is often called the internet's phonebook. It translates human-friendly domain names like `google.com` into IP addresses that computers use to communicate over the internet.
How DNS resolution works:
1. User types `youtube.com` in the browser.
2. Browser checks its local cache for the IP address.
3. If not found, it queries the Recursive Resolver (usually provided by the ISP).
4. The resolver queries the Root Name Server, then the TLD Name Server (.com), then the Authoritative Name Server.
5. The authoritative server returns the IP address.
6. Browser connects to the server at that IP.
Why DNS is important in system design:
For example, when a user types `youtube.com`, DNS resolves it to an IP address so the browser can connect to the correct server automatically.
What happens during a cache miss?
A cache miss occurs when requested data is not found in the cache, forcing the system to retrieve it from the main database or backend service.
Cache Miss Flow:
1. Client requests data.
2. System checks the cache — data is not found (cache miss).
3. System fetches the data from the primary database or backend.
4. The fetched data is stored in the cache for future requests.
5. The data is returned to the client.
Impact of cache misses:
Types of cache misses:
Cache Stampede: When many requests miss simultaneously and all hit the database at once — mitigated using locking or request collapsing.
For example, if a product's details aren't found in Redis cache, the application fetches it from the database, then caches it so subsequent queries are served from memory.
What is cache invalidation?
Cache invalidation is the process of removing or updating outdated data in the cache to ensure users receive accurate and current information. It is one of the hardest problems in distributed systems.
Why it matters:
Common Cache Invalidation Strategies:
TTL (Time-To-Live):
Write-Through Invalidation:
Manual/Event-Based Invalidation:
Cache-Aside with Invalidation:
For instance, in an e-commerce app, if a product's price changes in the database, the cached entry is invalidated so users see the latest price on their next request.
What occurs if the leader node fails in a distributed system?
In a distributed system, the leader node coordinates writes and critical decisions. If it fails, the system must detect the failure and elect a new leader to continue operating without manual intervention.
What happens step by step:
1. Other nodes detect the leader failure via missed heartbeats or timeouts.
2. A leader election algorithm is triggered automatically.
3. Nodes vote and a new leader is elected.
4. The new leader takes over coordination and write operations resume.
Common Leader Election Algorithms:
Raft:
Paxos:
Zookeeper (ZAB Protocol):
Key concerns during failover:
For example, in a distributed database cluster, if the primary server crashes, a replica is automatically promoted to leader to maintain write operations with minimal downtime.
How does auto-scaling function in distributed systems?
Auto-scaling automatically adjusts system resources by adding or removing servers based on current traffic or workload, maintaining performance while optimizing costs.
How it works:
1. A monitoring system continuously tracks metrics like CPU utilization, memory usage, request rate, or queue depth.
2. When a metric exceeds a defined threshold, the auto-scaler triggers a scale-out action (adds servers).
3. When traffic drops below a threshold, it triggers a scale-in action (removes servers) to reduce costs.
Types of Auto-Scaling:
Horizontal Auto-Scaling (Scale Out/In):
Vertical Auto-Scaling (Scale Up/Down):
Reactive vs Predictive Scaling:
For example, during a festival sale, an e-commerce platform automatically spins up more servers to handle increased traffic, then scales down when demand drops — balancing performance and cost.
What is a Sticky Session in load balancing?
Sticky Session (also called Session Persistence) is a load balancing technique that routes all requests from the same user to the same backend server throughout their session.
Why it's needed:
How it's implemented:
Trade-offs:
| Advantage | Disadvantage |
|---|---|
| Simple session consistency | Uneven load distribution |
| No shared session storage needed | Server failure loses session data |
| Works with legacy apps | Harder to scale horizontally |
Modern alternative: Use a centralized session store (e.g., Redis) so any server can handle any request — eliminating the need for sticky sessions.
For example, in an online store, sticky sessions keep a user's shopping cart consistent by directing all requests to the same server during checkout.
How does a load balancer determine if a server is functioning or has failed?
A load balancer continuously monitors backend servers using health checks to determine which servers are healthy and capable of handling requests.
How Health Checks Work:
Active Health Checks:
Passive Health Checks:
Common Health Check Types:
Recovery:
For example, if one of four servers running a food delivery app crashes, the load balancer detects the failure through missed health checks and routes all user requests to the remaining three healthy servers — ensuring uninterrupted service.