System Design (HLD)

Tests whether you know HLD is about system architecture and component boundaries, while LLD is about class-level implementation detail.

Tests whether you know to separate what a system does from how well it needs to do it (latency, scale, availability).

Tests whether you know the tradeoffs between adding more machines versus making one machine bigger.

Tests whether you can reason through caching, load balancing, sharding, and async processing together at extreme scale.

Tests whether you know why many clients retrying or waking up simultaneously can itself take a system down.

Tests whether you can scope a huge system design problem correctly before jumping to components.

Tests whether you know a persistent connection avoids the latency and overhead of constantly re-establishing HTTP requests.

Tests whether you know each tick maps to a distinct acknowledgment event traveling back through the delivery pipeline.

Tests whether you know messages queue server-side until the recipient's connection re-establishes, then flush in order.

Tests whether you know large-group fanout is a genuinely harder scaling problem than 1-on-1 messaging.

Tests whether you know the server never has the keys to read message content, and how key exchange still works per-device.

Tests whether you know media takes an entirely different storage/delivery path than lightweight text messages.

Tests whether you can combine acknowledgments, persistent queuing, and retry logic into a genuinely reliable delivery guarantee.

Tests whether you know a load balancer does more than just 'spread traffic' — health checks, TLS termination, and failover too.

Tests whether you know L7 can route on content (path, headers) while L4 only sees connection-level information.

Tests whether you know which algorithm fits which traffic pattern, especially when backend capacity is uneven.

Tests whether you know why pinning a user to one server helps stateful apps but hurts even load distribution.

Tests whether you know distributed ACID transactions don't scale, and Saga is the practical alternative.

Tests whether you can trace event-driven, peer-to-peer coordination step by step without a central coordinator.

Tests whether you can contrast this against choreography and explain when a central coordinator is actually worth the coupling.

Tests whether you can turn the abstract pattern into a concrete topic/event design.

Tests whether you know a Saga needs its own observability (state tracking, correlation IDs) since there's no single transaction log to inspect.

Tests whether you know 2PC's blocking, coordinator-dependent model doesn't fit the availability goals of microservices.

Tests whether you know the schema, scaling, and consistency tradeoffs, not just 'SQL is relational, NoSQL isn't.'

Tests whether you know these are two fundamentally different philosophies for what a database guarantees under failure.

Tests whether you can name real databases (like DynamoDB or Cassandra vs. traditional RDBMS) and place them correctly on CAP.

Tests whether you know range-based, hash-based, and directory-based sharding, and the hotspot risk each carries.

Tests whether you know why consistent hashing avoids remapping almost every key when a node is added or removed.

Tests whether you know how log-structured merge trees turn random writes into fast sequential ones for write-heavy databases.

Tests whether you know the practical configuration, not just that NGINX 'can do load balancing.'

Tests whether you know centralizing TLS termination simplifies certificate management and offloads CPU work from application servers.

Tests whether you know NGINX's event-driven, non-blocking architecture is what makes this possible on modest hardware.

Tests whether you know one hides the client from the server, and the other hides the server from the client.

Tests whether you know caching can happen at the browser, CDN, application, and database layer, each solving a different problem.

Tests whether you know the tradeoffs each caching strategy makes between latency, consistency, and complexity.

Tests whether you know which eviction policy fits which access pattern, and why LRU is the common default.

Tests whether you know how to stop thousands of requests from simultaneously hammering the database when a hot key expires.

Tests whether you know why one extremely popular key can overload a single Redis shard even when the cluster overall has headroom.

Tests whether you understand the actual proof intuition, not just the acronym.

Tests whether you know the coordination and conflict-resolution tradeoffs each replication model makes.

Tests whether you know each algorithm handles burstiness and window-boundary edge cases differently.

Tests whether you know the tradeoff between instant delivery cost and on-demand fetch cost at scale.

Tests whether you know statelessness is what makes horizontal scaling and failover trivial instead of painful.

Tests whether you know one splits a table by columns and the other by rows, and which one actually improves write scalability.

Tests whether you know the durability-versus-latency tradeoff each write strategy makes.

Tests whether you know how decoupling producers from consumers improves resilience and lets each side scale independently.

Tests whether you can explain Kafka's architecture at the system-design level, not just the API surface.

Tests whether you know why perfectly reliable communication over an unreliable network is provably impossible.

Tests whether you know how a distributed system agrees on a single coordinator without a single point of failure.

Tests whether you know how to coordinate mutual exclusion across multiple machines, not just within one process.

Tests whether you know how hash trees let two systems find data differences without comparing every single record.

Tests whether you can model a complex, permission-heavy, highly configurable domain, not just a simple CRUD app.

Tests whether you know operational transformation or CRDTs are what make concurrent editing actually converge correctly.

The most classic system design opener — tests encoding strategy, collision handling, and read-heavy scaling.

Tests whether you know when to move beyond database LIKE queries to a dedicated search engine like Elasticsearch.

Tests whether you can design delivery guarantees, message ordering, and real-time connections at massive scale. Asked at: Meta, Google, Uber

Tests whether you know the fanout-on-write versus fanout-on-read tradeoff for celebrity accounts with millions of followers. Asked at: Meta, X, Amazon

Tests whether you know channel-based fanout and message search have different scaling characteristics than 1-on-1 chat. Asked at: Salesforce, Microsoft, Atlassian

Tests whether you can combine partitioning, replication, and ordering guarantees into one coherent messaging backbone.

Tests whether you can design a pipeline for chunked upload, async transcoding, and adaptive bitrate streaming. Asked at: Google, Microsoft

Tests whether you know how ingestion, indexing, and query layers need to scale independently for a system like this.

Tests whether you can design geospatial indexing and real-time matching under tight latency constraints. Asked at: Uber, Lyft, Google

Tests whether you can design a distributed rate limiter, not just a single-process token bucket. Asked at: Amazon, Stripe, X

Tests whether you can design a pluggable trigger-action engine that scales across arbitrary third-party integrations.

Tests whether you can bring together consistent hashing, replication, and CAP tradeoffs into one coherent design. Asked at: Amazon

Tests whether you know a naive cron-per-instance setup breaks the moment you scale beyond one node.

Tests whether you can combine an atomic inventory decrement, a request buffer, and idempotency into one design under extreme concurrent load.

Tests whether you can design multi-channel fanout with retries, rate limiting per user, and provider failover.

Tests whether you can combine media storage, a ranking algorithm, and ephemeral content (stories) in one design. Asked at: Meta, Amazon

Tests whether you know how CDN edge caching and personalized recommendations combine at global streaming scale. Asked at: Netflix, Amazon

Tests whether you can reason about graph-based shortest-path routing combined with live traffic data at global scale. Asked at: Google

Tests whether you know how to guarantee exactly-once money movement and an auditable ledger under retries and failures. Asked at: Stripe, PayPal, Amazon

Tests whether you can reason about GPU batching, request queuing, and streaming token responses under massive concurrent load. Asked at: OpenAI, Google, Microsoft

Tests whether you can design the offline model training and online low-latency serving halves of a recommendation system. Asked at: Netflix, Amazon