System Design (HLD)

Tests whether you separate the wallet balance (a derived, cached number) from the immutable transaction ledger, and reconcile the two with a periodic batch job rather than trusting the balance column as source of truth.

Tests whether you reach for a saga with a compensating refund transaction (or an outbox-driven retry) instead of wrapping cross-service calls in a single ACID transaction that can't exist across service boundaries.

Tests whether you design the ledger as append-only double-entry bookkeeping with no destructive updates, so every balance is always derivable and verifiable from the full transaction history.

Tests whether you treat the transfer as a saga with a compensating debit-reversal step on failure, rather than assuming a two-phase commit across independently-owned account services is feasible.

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.

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.

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

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

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 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 can design geospatial indexing and real-time matching under tight latency constraints. Asked at: Uber, Lyft, Google

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

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 design multi-channel fanout with retries, rate limiting per user, and provider failover.

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

Tests whether you combine a doubly-linked list (or similar O(1) structure) for LRU/LFU ordering with lazy or background TTL expiry, instead of scanning all entries on every read to check staleness.

Tests whether you pick local cache for read-heavy, loosely-consistent data (accepting per-node staleness) and distributed cache only when consistency across nodes or shared capacity actually matters, rather than defaulting to Redis for everything.

Tests whether you keep validation and request/response mapping in the controller, business rules in the service, and persistence concerns isolated in the DAO, rather than leaking SQL or HTTP concepts across layers.

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 can translate a template/segment/trigger model into working code with a queue-backed fan-out and per-channel adapters, not just a component diagram with boxes labeled 'email service'.

Tests whether you apply exponential backoff with jitter and a dead-letter path after max attempts, rather than retrying immediately in a tight loop that can amplify an outage.

Tests whether you dedupe using an idempotency key per (user, event, channel) tuple checked before send, rather than relying on retry logic alone and hoping sends don't overlap.

Tests whether you use separate queues (or a priority queue with weighted consumers) per priority tier so high-priority alerts aren't stuck behind a backlog of low-priority bulk sends.

Tests whether you model the order book and matching engine with strict price-time priority and atomic order state transitions, rather than treating buy/sell as independent CRUD operations.

Tests whether you model jobs as a DAG and run a topological scan to release every job whose dependencies just completed, instead of serially walking dependency chains one at a time.

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 reach for bidirectional BFS over a sharded adjacency-list graph store to collapse search depth, rather than a naive single-direction BFS that explodes exponentially at scale.

Tests whether you decouple rule definitions (conditions and actions as data) from the evaluation engine so rules can be added without redeploying code, rather than hardcoding if/else chains per rule.

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 solve the meeting-rooms variant with a min-heap of end times (not brute-force interval overlap checks), then design Spotify's playlist/playback state separately from the song catalog so playback doesn't mutate shared data.

Tests whether you pick a decentralized ID scheme (pre-allocated ranges per region or Snowflake-style IDs) to avoid a single global counter becoming a cross-region bottleneck and conflict source.

Tests whether you model trades as immutable events with a separate settlement-status state machine, so a trade's history is never overwritten even as its settlement state changes.

Tests whether you treat each exchange feed as an independent source of truth reconciled via matching keys and tolerance windows, rather than assuming all exchanges report trades in the same format or timing.

Tests whether you push scoring into a low-latency streaming path with pre-computed feature aggregates (velocity counters, rolling windows) instead of querying historical transaction tables synchronously on every swipe.

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 partition the batch for parallel processing with checkpointing for restartability, instead of a single sequential pass that re-runs from scratch on any mid-batch failure.

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 partition the event stream by user ID (e.g., Kafka partition key) so ordering is guaranteed only within a partition, letting you scale throughput across partitions without a single global sequence.

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 decouple log shipping (local agents writing to a durable queue) from indexing/storage, so a downstream indexing slowdown doesn't cause logs to be dropped at the source.

Tests whether you reach for an atomic compare-and-set (or a distributed lock scoped to the driver ID) on the driver's availability state, so two concurrent match requests can't both win the same driver.

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

Tests whether you know a per-server in-memory counter is wrong across 40 servers (each enforces its own limit independently, so the real aggregate limit is 40x higher than intended), and that the counter must live in a shared store like Redis using an atomic INCR with TTL to avoid a check-then-increment race.

Tests whether you identify the actual bottleneck first (stateless app tier horizontal scaling is usually easy; the database and any shared stateful component are the hard part) rather than jumping straight to 'add more servers' without naming what needs caching, sharding, or read-replica offloading.

Tests whether your design isolates each channel behind its own circuit breaker/queue so a failing SMS provider degrades only SMS delivery (queuing or dropping with alerting) without affecting the independent email/push pipelines -- a single shared dispatcher without isolation would let one bad dependency stall everything.

Tests whether you reach for auto-scaling at the app tier combined with a connection pooler/proxy (like RDS Proxy) in front of the database, since app instances can scale fast but the database connection limit is fixed -- scaling app servers alone just multiplies connection pressure on the DB.

Tests whether you walk through the standard scaling levers in the right order -- caching, horizontal scaling behind a load balancer, database read replicas/sharding, and async processing for non-critical work -- grounded in where the actual bottleneck is, not a generic checklist.

Tests whether you argue for bypassing to the source of truth (DB) with a circuit breaker around the cache client, rather than treating cache availability as a hard dependency -- a cache should degrade performance when it's down, never cause an outage.

Tests whether you know a single load balancer is itself a single point of failure, and that the standard mitigation is redundant LBs behind a floating/virtual IP or DNS-based failover -- the system's resilience design is only as strong as its entry point.

Tests whether you favor graceful load shedding (rate limiting, queueing, prioritizing critical paths) over trying to serve every request at the cost of total system collapse -- a capacity-aware system degrades, it doesn't crash.

Tests whether you reference the CAP trade-off directly -- during a partition you must choose availability (serve possibly-stale data) or consistency (reject requests) -- and that the right choice depends on the specific operation, not a system-wide default.

Tests whether your design assumes multi-region failover with health-check-based DNS/traffic rerouting, and whether you've considered data replication lag between regions -- failover without replicated data just moves the outage, it doesn't fix it.

Tests whether you know split-brain means two nodes both believe they're the leader/primary after a partition, each accepting writes independently -- and that the fix is quorum-based consensus (requiring a majority to elect a leader) so only one side of the partition can ever have enough votes to act.

Tests whether you design for fast detection (canary rollout, automated health checks) and fast rollback as the real safety net -- rather than relying purely on pre-deploy testing to catch every breaking change before it reaches production.

Tests whether you have a concrete recovery sequence -- failover to a healthy replica/region, drain and restart affected instances, and replay any buffered/queued work -- rather than a vague 'restart it and see.'