System Design (HLD)

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 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.

A simpler cousin of the URL shortener: object storage for large text content (not just a short key-value pair), expiration handling, and a read-heavy caching strategy for popular pastes. Good for warming up estimation skills since the storage math is interesting (average paste size × daily pastes × retention period).

The 'sorted data at scale' problem: a relational database struggles with real-time rank queries at scale, which is exactly why Redis sorted sets (ZADD/ZRANK/ZREVRANGE) are the standard answer, giving O(log n) rank/update instead of a full sort on every query. At senior level, the probe extends to multi-dimensional rankings (daily/weekly/all-time) and historical leaderboard snapshots.

The read-heavy content delivery problem: content versioning, draft-vs-published state management, and how content is cached when it must be invalidated the instant something is published. The cache invalidation strategy on publish — pushing a fresh version out to every edge/cache layer without serving a stale draft — is the most interesting part.

The inventory-and-double-booking problem: how room availability is modeled and queried efficiently across date ranges, how concurrent bookings are prevented from double-booking the same room (locking vs optimistic concurrency), and how the booking and payment are completed as one consistent operation rather than two independently-failable steps.

The financial consistency and idempotency problem: how transfers between accounts are made atomic, how the system prevents double-charging on a retried request, and how transaction history is stored for auditability. Idempotency keys on every payment operation are the central design detail interviewers probe hardest.

The ingest-transcode-and-low-latency-delivery problem: how a live stream is ingested from a broadcaster, transcoded into multiple quality levels in near-real-time (unlike YouTube's offline transcode pipeline), and delivered to potentially millions of concurrent viewers with only a few seconds of latency.

The consistent-hashing-and-replication problem: how data is distributed across cache nodes using consistent hashing, how virtual nodes improve distribution evenness, what happens when a node fails, and how the cache handles a hot key that receives wildly disproportionate traffic compared to every other key.

The seat-inventory-and-concurrent-reservation problem: how seat availability is queried efficiently across many flights and dates, how two users racing to book the last seat on a flight are handled correctly, and how the booking and payment complete as one consistent operation.

The real-time-auction-and-targeting problem: how ads are selected and ranked within a strict millisecond budget, how targeting criteria are matched against user attributes at scale, and how impression/click events are collected reliably enough to be trusted for billing.

The petabyte-scale data-pipeline problem: how the web is crawled at scale, how HTML is parsed and content extracted, how an inverted index is built and continuously updated across hundreds of machines, and how index freshness is maintained. Expect to reason about a MapReduce-style (or equivalent) batch processing pipeline, not a single-machine design.

The multi-service saga problem at Amazon's scale: how an order touching payment, inventory, fulfillment, and notification services stays consistent when any one of those services can fail mid-flow, how the system handles an item going out of stock AFTER payment is already taken, and how order state is tracked reliably across the entire lifecycle.

The global-strong-consistency problem: how a database achieves strong consistency across geographically distributed nodes despite network delay, how a mechanism like TrueTime provides globally consistent timestamps, and what cross-region transactions actually cost in latency. This is asked almost exclusively for the most senior distributed-systems roles.

The large-scale ML-serving problem: the full pipeline from user-behavior data collection through offline model training to a real-time recommendation-serving layer, how recommendations get personalized for hundreds of millions of users, and how the system handles the cold-start problem for a brand-new user with no watch history yet.

The graph-at-social-network-scale problem: how billions of friendships and follow relationships are stored and queried, how the graph is partitioned across machines without making common queries prohibitively expensive, and how operations like mutual-friends or second-degree-connections execute efficiently at this scale.

The low-latency-state-synchronization problem: how game state stays synchronized across players in different geographic regions with minimal perceived lag, how conflicts are resolved when two players' actions affect the same game state simultaneously, and how matchmaking pairs players by both skill and geographic proximity.

The real-time-demand-sensing-and-pricing problem: how supply and demand are measured in real time across many geographic zones, how prices are computed and pushed to users within seconds of a demand shift, and — the hardest part — how the system avoids a feedback loop where a price change itself causes a demand change that triggers yet another price change.

The multi-region financial-consistency problem: how a payment system maintains strong consistency across regions while still meeting real-time payment latency requirements, how regulatory requirements in different jurisdictions constrain where data can physically be stored, and how currency conversion and settlement work across markets.

The real-time-bidding-at-enormous-scale problem: how billions of ad auctions per day are conducted within a millisecond budget, how targeting signals get applied at the moment of auction, how the billing system accurately tracks spend across billions of auctions, and how advertiser budget depletion is enforced in real time so no advertiser overspends.

The unified-identity-across-products problem: how user identities are linked across products that each have different underlying data models, how privacy requirements and regulatory constraints differ across products and jurisdictions, and how a change to one identity correctly propagates to every linked product.

The infrastructure-as-code-and-resource-management problem: how cloud resource requests are validated, queued, and executed across a global fleet, how capacity is managed so resources are actually available when requested, and how the system handles PARTIAL provisioning failures where some resources in a stack succeed and others fail.

The streaming-infrastructure-at-internet-scale problem: how a message queue processing trillions of messages a day is architected, how topics are partitioned and replicated across a global fleet of brokers, how consumer lag is monitored and managed, and how the platform survives the failure of an entire data center without losing messages or needing manual intervention.

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 can design delivery guarantees, message ordering, and real-time connections at massive scale. Asked at: Meta, Google, Uber

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

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 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 can design a pipeline for chunked upload, async transcoding, and adaptive bitrate streaming. Asked at: Google, Microsoft

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

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 pluggable trigger-action engine that scales across arbitrary third-party integrations.

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 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 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 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