Interview Hub

Walk in ready.

The exact questions companies ask — system design, LLD, HLD and core backend — each with a visual framework instead of a wall of text.

Filter by topic

Showing all questions.

System Design · HLD

Most-asked HLD questions

Tap a question for a framework to structure your answer — then go deep on the underlying concept.

01Design a URL shortener (like bit.ly)Easy
  • Scope it: generate a short unique code, redirect code → long URL, and survive a heavy read:write skew (~100:1 reads).
  • Key generation: base62-encode an auto-increment / Snowflake ID, or hand out ranges from a key-generation service — avoid hashing collisions.
  • Storage: a simple KV/SQL row keyed by the short code; the code is the primary index so redirects are O(1) lookups.
  • Scale reads: cache hot codes in Redis and let a CDN cache the redirect; 301 vs 302 changes how cacheable it is.
  • Trade-off: shorter codes mean fewer possible URLs; custom aliases need an extra uniqueness check.
→ Learn the concept: Databases & Indexing
02Design a rate limiter for a public APIMedium
  • Clarify: per-user or per-IP? Fixed window, sliding window, or token bucket? Reject the excess or queue it?
  • Core answer: a token bucket in Redis — store tokens + last-refill timestamp per key and refill lazily on each request.
  • Make it atomic: a Lua script (or INCR + EXPIRE) so concurrent requests can't over-spend the same bucket.
  • Distributed: shared Redis is the source of truth; per-node in-memory counters drift, so treat them as an approximation.
  • Trade-off: fixed window is cheap but allows 2× bursts at the boundary; a sliding-window log is accurate but memory-heavy.
→ Learn the concept: Caching
03Design a news feed (fan-out on read vs write)Medium
  • Two models: fan-out on write (push each post into every follower's feed) vs fan-out on read (pull and merge at request time).
  • Push: fast reads, expensive writes — painful for celebrities with millions of followers.
  • Pull: cheap writes, slow reads — better for very-high-follower accounts.
  • Hybrid is the real answer: push for normal users, pull for celebrities, merge the two at read time.
  • Mechanics: do fan-out asynchronously through a queue (Kafka) so posting stays fast.
→ Learn the concept: Messaging & Queues
04Design WhatsApp / a chat systemHard
  • Core needs: real-time delivery, presence, ordering, delivery/read receipts, and offline messages.
  • Connections: persistent WebSockets to a gateway layer; a session registry maps user → connected server.
  • Delivery: route through a queue so an offline recipient's messages are stored and flushed on reconnect.
  • Ordering: a per-conversation sequence number guarantees order; message IDs dedupe under at-least-once delivery.
  • Scale: shard by conversation/user; group chats fan out to each member.
→ Learn the concept: Networking & Protocols
05Design a distributed job schedulerHard
  • Requirements: run at a time (or cron), retries, at-least-once vs exactly-once, and visibility into runs.
  • Design: store jobs with a next-run timestamp; a poller / timer wheel moves due jobs onto a work queue.
  • Workers pull, run, and ack; a lease / visibility timeout re-queues a job if a worker crashes mid-run.
  • Idempotency keys stop double execution when a job is retried.
  • Scale: partition the schedule by time bucket or shard; send poison jobs to a dead-letter queue.
→ Learn the concept: Messaging & Queues
06Design a payment system with idempotencyHard
  • Non-negotiables: never double-charge, and never leave inconsistent state after a partial failure.
  • Idempotency: the client sends an idempotency key; the server records it so a retry returns the original result, not a second charge.
  • Flow as a saga: reserve funds → charge → update ledger, each step with a compensating action (release/refund) on failure.
  • Truth: an append-only ledger is the source of truth; derive balances from it.
  • Trade-off: orchestration is easier to reason about; choreography couples services less but is harder to debug.
→ Learn the concept: SAGA & Distributed Transactions
Core backend · LLD

Fundamentals they drill on

The building blocks every design leans on — know the trade-off for each.

07Design a distributed cache (like Redis Cluster)Hard
  • Partition keys across nodes so any client can locate a key without a central lookup.
  • Consistent hashing with virtual nodes so adding/removing a node remaps only ~1/N of keys, not the whole ring.
  • Replication: each shard keeps replicas for availability; decide read-from-replica vs read-from-primary.
  • Bounds: LRU/LFU eviction and TTLs cap memory; write-through vs cache-aside defines consistency with the database.
→ Learn the concept: Consistent Hashing
08Design typeahead / search autocompleteMedium
  • Goal: return top-k completions for a prefix in under ~100ms.
  • Precompute: a trie where each node caches its top-k completions, or an inverted index of prefix → ranked terms.
  • Ranking: by popularity/recency, updated asynchronously from a query log — never on the hot path.
  • Serve: cache hot prefixes at the edge; the long tail hits the trie service.
  • Trade-off: precomputed top-k is fast but slightly stale; live aggregation is fresh but slow.
→ Learn the concept: Databases & Indexing
09Design a CDN for global static assetsMedium
  • Goal: serve static (and cacheable dynamic) content from a POP near the user.
  • Caching: cache key = URL + relevant headers; TTLs come from Cache-Control; an origin shield protects the origin.
  • Invalidation is the hard part: use versioned/hashed asset URLs so every deploy is a new key — no purge needed.
  • Routing: terminate TLS at the edge and send users to the nearest POP via anycast / GeoDNS.
→ Learn the concept: CDN & Edge
10Design a load balancerMedium
  • Job: spread traffic across healthy backends and pull failed ones out of rotation.
  • L4 vs L7: L4 (TCP) is fast and protocol-agnostic; L7 (HTTP) routes by path/host and can do TLS + retries.
  • Algorithms: round-robin, least-connections, or consistent hashing when you need session/cache affinity.
  • Health: active/passive health checks eject bad instances; sticky sessions trade even spread for affinity.
→ Learn the concept: Load Balancing
11Scale a read-heavy databaseMedium
  • First, the cheap wins: add the right indexes and cache reads before touching topology.
  • Read replicas: route reads to followers; writes go to the primary (leader–follower replication).
  • Replica lag: async replication means reads can be stale — use read-your-writes routing for the writer's own reads.
  • When one primary can't take the writes, shard by a key; cross-shard queries and rebalancing are the price.
→ Learn the concept: Replication & Sharding
12Design authentication & authorizationMedium
  • Separate the two: authentication proves who you are; authorization decides what you can do.
  • Sessions: a signed JWT (short-lived access + refresh) scales horizontally; server-side sessions are easier to revoke.
  • Delegation: third-party login via OAuth2 / OIDC; never store passwords in plaintext — hash with bcrypt/argon2 + salt.
  • Permissions: model with RBAC (roles) or ABAC (attributes); enforce at the gateway and again in the service.
→ Learn the concept: Auth & Security
13When would you split a monolith into microservices?Medium
  • Don't rush it: a monolith is simpler until real team/scale pain shows up.
  • Split along business capabilities / bounded contexts, not technical layers; each service owns its data.
  • Comms: sync (REST/gRPC) for request-response, async events to decouple; an API gateway fronts clients.
  • New failure modes: network calls fail — add timeouts, retries with backoff, circuit breakers, and tracing.
  • Trade-off: independent deploys and scaling vs distributed-systems complexity and eventual consistency.
→ Learn the concept: Microservices
14Design an order system with CQRSHard
  • Split the write model (commands that change state) from the read model (queries) when their shape or scale differs.
  • Writes append events/records; read models are denormalized projections built per query and updated from the write side.
  • Payoff: reads scale independently and stay fast; the cost is eventual consistency between the two models.
  • Pairs with event sourcing: treat the event log as truth and rebuild/replay projections from it.
→ Learn the concept: CQRS & Event Sourcing
15Consistency vs availability — CAP in practiceHard
  • Under a partition you must choose: stay consistent (reject) or stay available (serve possibly-stale data).
  • Per operation, not per system: payments lean CP; feeds and likes lean AP.
  • PACELC extends it: even with no partition you trade latency vs consistency (sync vs async replication).
  • Be explicit: name the consistency model — strong, read-your-writes, or eventual — because it drives the whole design.
→ Learn the concept: Trade-offs & CAP
Company-wise

Prep by where you're interviewing

Curated sets in the style of each company's rounds — generic best-practice, no confidential material.

G Google A Amazon

More company sets (Microsoft, Uber, Flipkart, Razorpay…) dropping soon.

G Google

01Design a global rate limiter across regionsHard
  • Same token-bucket core, but the limit must hold globally, not per datacenter.
  • Two options: a central store (accurate, higher latency) vs per-region buckets each holding a slice of the global limit (fast, approximate).
  • Reconcile counters asynchronously and accept small overshoot for lower latency.
  • Decision: fail open vs fail closed when the limiter store is unreachable.
→ Learn the concept: Caching
02Design a web crawlerHard
  • Frontier queue of URLs; workers fetch, parse, extract links, and enqueue new ones.
  • Dedupe with a seen-set (bloom filter + store) so you don't re-crawl; respect robots.txt and per-domain politeness limits.
  • Prioritize the frontier by freshness/importance; a DLQ catches pages that keep failing.
  • Scale with many stateless fetchers behind the shared queue; partition by domain to keep politeness local.
→ Learn the concept: Messaging & Queues
03Design Google Docs (collaborative editing)Hard
  • The hard bit: many users edit the same doc concurrently and see each other live.
  • Concurrency control: Operational Transform or CRDTs merge concurrent edits without conflicts.
  • Transport: clients hold WebSockets to an edit server that sequences ops and broadcasts them; persist an op log for recovery.
  • Extras: presence/cursors, and periodic snapshots so opening a doc doesn't replay the entire op log.
→ Learn the concept: Networking & Protocols

A Amazon

01Design an e-commerce order systemHard
  • One order spans inventory, payment, and shipping — a distributed transaction.
  • Model as a saga: reserve inventory → charge payment → create shipment, each with a compensating rollback.
  • Idempotency keys stop a client retry from creating duplicate orders.
  • State: keep an order state machine (created → paid → shipped) and an event log for auditability.
→ Learn the concept: SAGA & Distributed Transactions
02Design a notification serviceMedium
  • Goal: send email/SMS/push across channels at high volume without blocking producers.
  • Pipeline: producers publish to a queue; per-channel workers consume and call the provider; retries + DLQ absorb provider failures.
  • Guardrails: deduplicate and rate-limit per user; store templates and user preferences / opt-outs.
  • Delivery: at-least-once means consumers must be idempotent.
→ Learn the concept: Messaging & Queues
03Design a distributed logging / metrics pipelineHard
  • Goal: ingest huge log volume, make it queryable, and lose nothing on node failure.
  • Pipeline: buffer through a durable log (Kafka) → stream processors → a time-partitioned indexed store.
  • Durability: replicate partitions across nodes; retention/rollup policies bound cost.
  • Trade-off: index everything (fast search, expensive) vs sample/aggregate (cheap, lossy).
→ Learn the concept: Replication & Sharding
Free with email

Get the 50 System Design Questions PDF

Every question here, plus 44 more — each with a one-line framework to structure your answer.