High-Level Design — 50 Q&A

HLD defines the overall architecture — the major modules, how they interact, and cross-cutting concerns like scalability, security, and technology choices. Typical components: clients, a load balancer, application services, one or more databases, a cache, a message queue, and a CDN, plus the communication paths between them.

It depends on application size, expected scale, complexity, and team structure. A monolith is easier to build and deploy but harder to scale as it grows; microservices allow independent scaling, deployment, and tech choices but add operational and communication complexity. Start monolithic if the app is small and refactor toward microservices as you grow.

Relational (SQL) offers ACID, strong consistency, complex joins, and structured schemas; NoSQL offers flexible schemas, horizontal scalability, and high performance on large distributed workloads, usually with eventual consistency. Many systems use both.

Handling growing users, traffic, and data without degradation via horizontal scaling, caching, partitioning, database replication, asynchronous processing, and distributed infrastructure.

Define resources and endpoints, request/response formats, and communication standards, then add authentication, rate limiting, versioning, and documentation.

Resource-oriented URIs, standard HTTP methods and status codes, statelessness, versioning, and content negotiation — yielding scalable, standardized, maintainable APIs.

Horizontal (scale out) adds machines for scalability and fault tolerance and needs a load balancer; vertical (scale up) upgrades one machine’s CPU/RAM, simple but limited by a hardware ceiling and a SPOF.

As a single entry point for client requests: it routes to backend services and centralizes cross-cutting concerns — authentication, rate limiting, logging, request aggregation, and monitoring — giving clients one unified interface.

A server that receives client requests and forwards them to backends on their behalf, adding load balancing, caching, security, and routing while hiding backend details. An API gateway is a specialized reverse proxy.

A stateful system stores session/client state, so requests depend on prior ones, making it harder to scale. A stateless system keeps no client state on the server, so every request is independent — easy to scale and load-balance.

Keep the system operational during failures and heavy load by eliminating single points of failure — through redundancy, replication, load balancing, failover, monitoring, and disaster recovery.

Distributing incoming traffic across servers for optimal utilization, high availability, and performance — preventing overload and removing single points of failure.

Build protection into every layer: authentication, authorization, encryption, and secure APIs, plus monitoring, logging, input validation, and a zero-trust posture.

Keeping the system functioning even when components fail, via redundancy, replication, failure isolation, and graceful degradation.

Ensure quick recovery from major failures with backups, geo-replication, and automated failover, guided by a defined RPO (max acceptable data loss) and RTO (max acceptable downtime).

Redundant network paths, load balancing, and dynamic routing so there’s no single point of failure, plus isolation, security, and disaster recovery.

Latency is the response delay for a single request; throughput is requests handled per unit time; availability is the percentage of uptime.

It automatically adds or removes servers based on live metrics — CPU, memory, request count — to maintain performance while optimizing cost.

Session persistence routing a user’s requests to the same backend server for the session (via cookie, IP, or session id), so session data stays available without cross-server sharing. The trade-off is that it undermines even load distribution.

Through continuous health checks/heartbeats at fixed intervals; a server that stops responding or errors repeatedly is marked failed and removed from rotation.

A structure that speeds retrieval so the database locates records without scanning the whole table — a big query speedup at the cost of extra storage and slightly slower writes.

With distributed transactions, idempotent operations, and conflict resolution, choosing strong vs eventual consistency per business need in line with CAP.

Ensure multiple users/processes safely access shared data via locking, isolation levels, and MVCC — preventing dirty reads, lost updates, and inconsistent state.

Copying and maintaining the same data across servers for high availability, fault tolerance, and read scalability.

Keep data accurate and reliable through constraints, validation, and ACID transactions, plus checksums, encryption, logging, and error handling.

A distributed system guarantees only two of Consistency, Availability, and Partition tolerance; since partitions are unavoidable, you effectively choose CP or AP.

Both split large datasets. Partitioning divides data within a single database instance; sharding distributes data across multiple servers for scale.

A distributed hashing technique spreading data across servers on a ring while minimizing data movement when servers change — only about 1/N of keys move.

ACID (relational) means strong consistency and strict transactions, prioritizing accuracy. BASE (NoSQL) means Basically Available, Soft state, Eventual consistency, prioritizing availability and scale.

The requested data isn’t in the cache, so the system fetches it from the slower backend and usually stores it for next time — a temporary latency increase that improves future reads.

Removing or updating stale cache entries so users get current data, via TTL, write-through updates, or manual invalidation — famously one of the two hard things in computer science.

It tracks memory usage on every add/update, and when the total exceeds the configured limit it triggers an eviction policy (LRU/LFU) to free space.

A cache stored across multiple nodes rather than one machine, giving faster, scalable access, reduced database load, and fault tolerance through replication.

Caching stores hot data in fast memory to cut response time and DB load, updated via write-through, write-back, cache-aside, or write-around — chosen by consistency needs and read/write pattern.

A distributed network of edge servers that cache and deliver content near users, lowering latency, reducing origin load, and speeding global delivery — typically static content.

Components communicate through events rather than direct synchronous calls, making the system loosely coupled, asynchronous, scalable, and resilient; producers emit events and consumers process them via a broker.

Middleware enabling asynchronous communication — receiving, storing, and forwarding messages — decoupling services for scalability, reliability, and fault isolation through buffering.

A mechanism by which distributed nodes select one leader/coordinator to handle centralized tasks — writes, scheduling, synchronization — to avoid conflicts.

They enable asynchronous communication so services exchange data without direct dependencies, reducing coupling and bottlenecks and improving scalability and reliability by buffering messages and absorbing spikes.

Synchronous: the sender waits for a reply (tighter coupling, possible delays). Asynchronous: the sender continues without blocking (better scalability and responsiveness).

A fault-tolerance pattern that stops repeated calls to a failing service to prevent cascades and allow recovery, cycling Closed (normal) → Open (fail fast) → Half-Open (test) → Closed.

A mechanism letting services find and communicate with each other dynamically without hardcoded addresses, automatically tracking changing instances.

The remaining nodes detect the failure through heartbeats/timeouts and run a leader election (e.g. Raft or Paxos) to promote a new leader, restoring operation without manual intervention.

Controlling how many requests a client can send in a time window to prevent abuse, overload, and DoS and ensure fair usage; a common algorithm is the token bucket, often enforced at the API gateway.

Packaging apps with dependencies into isolated containers for consistent execution across environments, resource efficiency, easy scaling (via Kubernetes), and fault isolation between microservices.

Secure sensitive data across its lifecycle with encryption, access control, and data masking, plus compliance, auditing, and regular assessments.

A seven-layer conceptual framework standardizing network communication, each layer with a specific function, simplifying interoperability and troubleshooting: Application, Presentation, Session, Transport, Network, Data Link, Physical.

The practical four-layer model behind the internet — Application, Transport, Internet, Network Access — using protocols like TCP, IP, HTTP, and UDP.

HTTP is plaintext on port 80 and less secure; HTTPS is encrypted via SSL/TLS on port 443 and secure for sensitive data.

TCP is connection-oriented, reliable, and ordered but slower (acknowledgments, error-checking) — for accuracy (web, file transfer). UDP is connectionless, faster, and low-overhead with no delivery guarantee — for speed (gaming, live video).

The Domain Name System translates human-readable domain names into IP addresses so machines can locate each other — the phonebook of the internet.

HLD is the overall architecture — modules, databases, APIs, scalability — from the planning phase, architecture-oriented. LLD is the detailed implementation — classes, methods, object interactions — just before coding, code-oriented.