System design revision notes

Must-know points

• Client: the app or browser the user holds.
• DNS: turns a name (example.com) into a server's address.
• CDN: servers around the world that keep copies of files close to users.
• Load balancer: spreads requests across many servers and skips broken ones.
• App server: runs your code; usually stateless, so you can add more.
• Cache: fast memory holding copies of often-read data (often Redis).
• Database: the permanent, trusted store of your data.
• Queue and workers: a waiting line of jobs, and the background programs that do them.
• Object storage: cheap, huge storage for files like photos and videos (for example Amazon S3).

Common mistakes

• Learning tool names (Redis, Kafka) before knowing what job each box does.
• Thinking every system needs every box. A small app may only need one server and one database.
• Treating the cache as the place where data really lives. The database is the source of truth.

Must-know points

• 1. Requirements (about 5 min): functional (what it does) and non-functional (scale, latency, availability, consistency). Write them down.
• 2. Estimates (about 3 min): users, requests per second, storage, bandwidth. Only as much as changes a decision.
• 3. API (about 3 min): the main endpoints with inputs and outputs.
• 4. Data model (about 3 min): the main entities, and which kind of database fits.
• 5. High-level design (about 10 min): the simplest design that works end to end.
• 6. Deep dives (10–15 min): fix the bottlenecks — caching, sharding, queues, failure handling.
• 7. Wrap-up: the trade-offs you made, what you'd do with more time, how you'd monitor it.

Common mistakes

• Designing before asking a single question.
• Adding Kafka, microservices and sharding to a system that gets 10 requests a second.
• Long silences. The interviewer can only give credit for what you say.
• Never stating trade-offs. Every choice has a cost, and naming it is what earns the strongest marks.

Must-know points

• Use powers of ten for speed: KB ≈ 10³ bytes, MB ≈ 10⁶, GB ≈ 10⁹, TB ≈ 10¹², PB ≈ 10¹⁵.
• Seconds per day ≈ 10⁵. Requests per day ÷ 10⁵ ≈ requests per second.
• Read-to-write ratio matters: many apps read 10–100 times more than they write, which points to caching and read replicas.
• Latency ladder: memory read ≈ 100 ns; SSD read ≈ 100 µs; round trip inside a datacentre ≈ 0.5 ms; across a continent and back ≈ 100–150 ms.
• Storage = items per day × size × days kept × copies (often 3 for replication).
• Rough capacity: one app server handles thousands of simple requests per second; one SQL database handles thousands to tens of thousands of simple queries per second.

Common mistakes

• Spending 10 minutes on exact arithmetic. Round hard: 86,400 ≈ 100,000.
• Using the average and forgetting the peak.
• Mixing up bits and bytes: network speeds are in bits, so 1 Gbps ≈ 125 MB a second.
• Working out numbers and then never using them to make a decision.

Must-know points

• 1. Clarify requirements and scope: the main use cases, what's out of scope.
• 2. Identify entities (nouns) and actions (verbs) from the use cases.
• 3. Draw a class diagram: fields, methods, relationships (composition, inheritance, interfaces).
• 4. Apply patterns where behaviour varies: Strategy, State, Factory, Observer.
• 5. Code the core flows with clean names; skip trivial getters.
• 6. Discuss concurrency (two users at once), edge cases and extensibility.
• Use SOLID to justify your choices out loud.

Common mistakes

• One giant class (a 'god class') that does everything.
• Deep inheritance trees where composition would be simpler.
• Using patterns that don't fit, just to mention them.
• Ignoring concurrency when two users can act on the same thing.

Must-know points

• DNS lookup order: browser cache → operating system cache → resolver (for example your ISP) → root server → top-level domain (.com) → the domain's authoritative server.
• TCP gives reliable, ordered delivery. UDP is faster but packets can be lost; it suits video calls, games and DNS itself.
• TLS (the S in HTTPS) encrypts the connection and proves the server's identity with a certificate.
• Every new connection costs round trips, so clients reuse connections (keep-alive, HTTP/2).
• IP address = which machine; port = which program on it (443 for HTTPS).

Common mistakes

• Forgetting DNS caching when you plan a failover by changing DNS records.
• Mixing up TCP (the reliable connection) with HTTP (the request format that travels over it).
• Thinking HTTPS only encrypts. It also proves the server's identity.

Must-know points

• Methods: GET reads (safe), POST creates, PUT replaces, PATCH changes part, DELETE removes. GET, PUT and DELETE should be idempotent.
• Status codes: 2xx success (200, 201), 3xx redirect (301, 302), 4xx client error (400, 401, 403, 404, 409, 429), 5xx server error (500, 503).
• Pagination: offset (simple, but slow and unstable on big, changing lists) or cursor (fast and stable; preferred at scale).
• Idempotency key: the client sends a unique key so a retried request isn't processed twice. Essential for payments.
• Versioning: /v1/ in the path or a header, so old clients keep working.
• Alternatives: GraphQL (the client chooses the fields it wants) and gRPC (fast, typed calls between services).

Common mistakes

• Returning 200 OK with an error message hidden in the body.
• Using GET for actions that change data (crawlers and browser prefetching may call it).
• No pagination, so one request can return a million rows.
• Breaking changes without a new version.

Must-know points

• Short polling: simple, but most responses are empty; high load, and a delay of up to one polling interval.
• Long polling: fewer empty responses; works everywhere; one request per message.
• WebSockets: two-way and low latency, but connections are stateful, which makes load balancing and scaling harder.
• SSE: one-way, server to client, over normal HTTP; reconnects automatically; good for feeds and notifications.
• Stateful connections need a 'who is connected where' registry, often in Redis.

Common mistakes

• Choosing WebSockets for one-way updates, where SSE is simpler.
• Forgetting that open connections make servers stateful: you need a connection registry and reconnect logic.
• No plan for messages missed while a client was disconnected.

Must-know points

• Best for static, popular, cacheable content: images, video segments, JavaScript and CSS files.
• Pull CDN: fetches from your origin server on a cache miss. Push CDN: you upload content ahead of time.
• Control freshness with TTL headers; put a version or hash in file names (app.3f9a.js) so updates appear immediately.
• Also helps with DDoS protection, and can handle TLS close to the user.

Common mistakes

• Caching personalised pages at the edge, and showing one user's data to another.
• Long TTLs on files that change, without versioned names.
• Forgetting that the first request in each region is still slow (a 'cold' cache).

Must-know points

• Forward proxy: acts for clients (for example, a company's web proxy). Reverse proxy: acts for servers.
• Gateway jobs: routing, authentication, rate limiting, TLS, request logging, API versioning.
• A load balancer spreads traffic across copies of a service; a gateway decides what's allowed and which service it goes to. Many products do both.
• Keep business logic out of the gateway.

Common mistakes

• Putting business rules in the gateway, so it slowly becomes a hidden monolith.
• Running a single gateway instance: a single point of failure.
• Doing heavy work in the gateway that slows down every request.

Must-know points

• Stateless app servers plus a shared session store = easy horizontal scaling.
• Databases are the hard part: read replicas for more reads, sharding for more writes.
• Scale the real bottleneck: measure first (CPU, memory, database, network).
• Auto-scaling adds and removes servers based on load.
• Scalability is not speed: a system fast for one user can still collapse under many.

Common mistakes

• Adding app servers when the database is the real bottleneck.
• Keeping sessions in server memory, then adding more servers.
• Sharding far too early: it adds a lot of complexity.

Must-know points

• Downtime per year: 99% ≈ 3.65 days; 99.9% ≈ 8.8 hours; 99.99% ≈ 53 minutes; 99.999% ≈ 5 minutes.
• Dependencies in series multiply availability down; parallel copies multiply the chance of failure down.
• Remove single points of failure: load balancers, databases, DNS, the gateway itself.
• Spread across availability zones (separate datacentres in one region); for more safety, across regions.
• Active–passive: a standby takes over. Active–active: all copies serve traffic all the time.
• SLI = what you measure; SLO = your target; SLA = your contract.

Common mistakes

• Two copies that share one point of failure (the same rack, the same power supply, the same bad deployment).
• Forgetting the database, DNS or load balancer when removing single points of failure.
• Promising 99.99% when one of your dependencies only offers 99.9%.

Must-know points

• Always set timeouts on network calls.
• Only retry safe (idempotent) operations; use exponential backoff plus random jitter to avoid retry storms.
• Circuit breaker states: closed (normal) → open (fail fast) → half-open (test) → closed.
• Graceful degradation: lose a feature, not the whole product.
• Cascading failure: a slow service ties up threads in the services calling it, which then slow down too.
• Test it: chaos engineering breaks things on purpose, in a controlled way.

Common mistakes

• No timeouts, or a timeout longer than the caller's own timeout.
• Retrying operations that aren't safe to repeat, like charging a card.
• Retrying instantly without backoff, which turns a small outage into a big one.

Must-know points

• Algorithms: round robin, weighted round robin, least connections, IP or consistent hashing.
• Health checks remove failed servers automatically.
• Layer 4: fast and protocol-agnostic. Layer 7: smarter routing and TLS handling, but more work per request.
• Sticky sessions tie a user to one server; avoid them by keeping servers stateless.
• The load balancer itself must be redundant (a pair, or a managed service).
• Load balancers are also used between internal services, not only at the edge.

Common mistakes

• Sticky sessions that tie one user to a server forever, which breaks when that server dies.
• Health checks that only test 'is the process running?', not 'can it reach its database?'.
• Forgetting that the load balancer needs redundancy too.

Must-know points

• Cache-aside (lazy loading): check the cache → on a miss, load from the database and fill the cache. The most common pattern.
• Write-through: write the cache and database together (fresh, but slower writes). Write-back: write the cache, save to the database later (fast, but data can be lost).
• Eviction: LRU (least recently used), LFU (least frequently used), TTL expiry.
• Invalidation: delete or update the cache entry when the data changes; the TTL is your safety net.
• Problems to know: stale data, cache stampede (many misses at once), hot keys, cold start.
• Cache only data that is read often and can be slightly out of date.

Common mistakes

• Caching data that changes constantly, or is hardly ever read.
• No TTL, so stale data lives forever if one invalidation is missed.
• No plan for a stampede when a very popular key expires.
• Treating the cache as the source of truth. It can be emptied at any moment.

Must-know points

• C = every read sees the latest write; A = every request gets a non-error response; P = the system keeps working when messages between machines are lost.
• Partitions are unavoidable in distributed systems, so it's CP or AP during a partition.
• Consistency levels: strong, read-your-own-writes, monotonic reads, eventual.
• Quorums: with N copies, writing to W and reading from R where W + R > N means every read overlaps the latest write.
• PACELC: even without partitions, stronger consistency costs latency.
• CAP's C is not ACID's C (which is about the database's rules and constraints).

Common mistakes

• Calling a system 'CA'. With replicas, partitions can't be wished away.
• Treating CAP as one choice for the whole system, instead of a choice per type of data.
• Confusing CAP's consistency with ACID's consistency.

Must-know points

• Token bucket: allows bursts up to the bucket size, with a steady refill rate. The most common.
• Leaky bucket: processes requests at a fixed rate; smooths out bursts.
• Fixed window: a simple counter per minute, but allows double bursts at the window edges.
• Sliding window (log or counter): smoother and fairer, slightly more work.
• Limit by user, API key or IP address; return 429 with a Retry-After header.
• Backpressure: bounded queues, load shedding, and signalling clients to slow down.

Common mistakes

• Limiting per server instead of across all servers.
• One global limit, so a single heavy user blocks everyone else.
• Unbounded queues that hide overload until memory runs out.

Must-know points

• Queue (SQS, RabbitMQ): spreads work; each message is consumed once, then deleted.
• Log or stream (Kafka): ordered, durable, replayable; partitions give order per key and parallel processing.
• Delivery guarantees: at most once, at least once (the most common), exactly once (hard; usually 'effectively once' with idempotent consumers).
• Dead-letter queue: where messages go after failing too many times.
• Pub/sub: one event fans out to many subscribers.
• Async means eventual: the user sees 'processing', not the final result straight away.

Common mistakes

• Assuming each message arrives exactly once. It can arrive twice, so make processing idempotent.
• Expecting order across a whole Kafka topic. Order is only kept within one partition.
• Using a queue where the user needs an immediate answer.

Must-know points

• The four golden signals: latency, traffic, errors, saturation.
• Use percentiles (p50, p95, p99), not averages; averages hide the slow users.
• Structured logs (JSON), with a request or trace ID on every line.
• Distributed tracing (OpenTelemetry) shows the time spent in each service.
• Alert on SLO burn (user impact), and give every alert a runbook.
• Health checks and a dashboard per service.

Common mistakes

• Alerting on causes (CPU at 80%) instead of symptoms users feel (errors, slow responses).
• Logs without a request or trace ID, so you can't connect them.
• Watching averages instead of percentiles.

Must-know points

• Choose by access pattern: what are the main reads and writes, and by which key?
• SQL: joins, ACID transactions, a strict schema; scales with replicas and, with more effort, sharding.
• Key-value: very fast by key, no complex queries. Document: flexible schema, nested data.
• Wide-column (Cassandra): massive write volume; queries designed around the partition key.
• Graph: relationships first (friends of friends).
• Default in most interviews: start with SQL unless there's a clear reason not to.
• Hands-on: the SQL tab teaches the language itself, from SELECT to window functions, with every query runnable.

Common mistakes

• Choosing NoSQL because it 'scales', without checking the queries you need.
• Designing a NoSQL schema like SQL tables, then needing joins.
• Forgetting that different parts of one system can use different databases.

Must-know points

• Anomalies: dirty reads, non-repeatable reads, phantom reads, lost updates, write skew.
• Read committed (a common default) stops dirty reads; repeatable read or snapshot stops non-repeatable reads; serializable stops all of them but is slowest.
• Lost-update fixes: SELECT … FOR UPDATE (pessimistic lock) or a version column (optimistic locking).
• Durability comes from a write-ahead log saved to disk before the commit is confirmed.
• Distributed transactions (two-phase commit) exist but are slow and fragile; prefer sagas across services.
• Hands-on: the SQL tab, Phase 6, runs real BEGIN, COMMIT and ROLLBACK examples.

Common mistakes

• Checking a balance in one query and updating it in another without a lock: a lost update.
• Assuming the default isolation level prevents every anomaly.
• Keeping a transaction open for a long time (for example, while calling another service), which holds locks and blocks others.

Must-know points

• B-tree: equality and range queries, and ORDER BY. Hash index: equality only.
• A composite index on (a, b) helps queries on a, or on a and b, but not on b alone (the leftmost-prefix rule).
• Covering index: contains every column the query needs, so the table itself isn't read.
• Every index slows writes and uses storage; index for your real queries only.
• Use EXPLAIN to check whether a query uses an index.
• LSM trees (Cassandra, RocksDB): very fast writes, merged in the background.
• Hands-on: the SQL tab, Phase 7, shows real query plans before and after adding an index.

Common mistakes

• Indexing every column 'just in case'.
• A composite index with the columns in the wrong order.
• Wrapping the column in a function (WHERE LOWER(email) = …) so the index can't be used.

Must-know points

• Leader–follower: simple and common; all writes go through one leader.
• Synchronous: no data loss on failover, but slower writes. Asynchronous: fast, but recent writes can be lost.
• Replication lag causes stale reads; fixes include read-your-own-writes and monotonic reads.
• Failover: detect that the leader is dead, promote a follower, redirect writes. Risk: split brain.
• Multi-leader: writes in several regions; conflicts need rules (last write wins, merging).
• Leaderless (Dynamo-style): quorums with W + R > N.

Common mistakes

• Reading from a replica straight after a write, and being surprised by old data.
• Fully asynchronous replication for data you can't afford to lose.
• Automatic failover with no protection against two leaders (split brain).

Must-know points

• A good shard key: many distinct values, an even spread, and it matches the main access pattern.
• Hash sharding: even load, poor for ranges. Range sharding: good for ranges, risk of hot spots.
• Hot keys (a celebrity) can overload one shard: split them further, or cache them.
• Cross-shard joins and transactions are hard: design so you don't need them.
• Resharding is painful; consistent hashing or many small logical shards make it easier.
• Shard only when needed: try caching, read replicas and a bigger machine first.

Common mistakes

• A shard key with few values (like country), which creates huge, uneven shards.
• A time-based key that sends every new write to the same shard.
• Designs whose common requests need joins or transactions across shards.

Must-know points

• hash % N moves most keys whenever N changes.
• The ring: a key belongs to the first server clockwise from it.
• Adding or removing a server moves about 1/N of the keys.
• Virtual nodes even out the load and spread a dead server's keys across many others.
• Used in: Cassandra, DynamoDB, distributed caches, some load balancers.

Common mistakes

• Too few virtual nodes, so the load is uneven.
• Assuming it fixes hot keys. It doesn't.
• Forgetting replication: each key usually lives on the next 2–3 servers on the ring, not just one.

Must-know points

• Big binary data goes in object storage; the metadata and key go in the database.
• Pre-signed URLs let clients upload or download directly and securely, for a limited time.
• Very durable (S3 is designed for 99.999999999%, 'eleven nines') and cheap per GB.
• Storage classes: hot (frequent access) and cold or archive (cheap, slow to get back).
• Large uploads use multipart upload: in chunks, retryable and resumable.

Common mistakes

• Putting files in database BLOB columns.
• Making a storage bucket public by accident.
• Sending big uploads through your own app servers.

Must-know points

• Inverted index: each term → a list of document IDs (a posting list).
• Text analysis: lowercase, split into words, drop stop words, reduce words to their stem.
• Ranking: TF-IDF or BM25 relevance, plus business signals like popularity.
• The database stays the source of truth; keep the search index in sync with change events.
• Search results are eventually consistent with the database.

Common mistakes

• Making the search engine the source of truth.
• Forgetting that new or changed items take a moment to become searchable.
• Using LIKE '%word%' on large tables.

Must-know points

• Auto-increment: simple, but a single point of failure and a bottleneck, and it reveals your counts.
• UUID v4: no coordination, 128 bits, random order (bad for inserts into a B-tree index).
• UUID v7 and ULID: ordered by time and still need no coordination.
• Snowflake: 64 bits, sortable by time; needs unique machine IDs and sane clocks.
• Range allocation: each server reserves a block of, say, 1,000 IDs at a time.

Common mistakes

• Two machines accidentally sharing a machine ID.
• Ignoring clock problems.
• Exposing sequential IDs that let outsiders count your orders or guess other users' links.

Must-know points

• Each service owns its data; services don't share a database.
• They communicate through APIs (synchronous) or events (asynchronous).
• You'll need: service discovery, an API gateway, distributed tracing, and a deployment pipeline per service.
• Data consistency across services is eventual; use sagas for multi-step workflows.
• Conway's law: a system's structure tends to mirror the teams that build it.

Common mistakes

• Splitting by technical layer (a 'database service') instead of by business capability.
• Chains of synchronous calls six services deep.
• A small team starting a new product as 30 microservices.

Must-know points

• Two-phase commit (2PC) gives an atomic commit across databases, but blocks on failures and couples services.
• Saga = local transactions + compensating actions.
• Choreography: decentralised, event-driven, but hard to follow as it grows. Orchestration: a central workflow, clearer, one more component.
• Outbox pattern: avoids the dual-write problem (the database update succeeds but publishing the event fails).
• Every step and compensation must be idempotent, because messages can arrive twice.

Common mistakes

• Forgetting compensations, or making them unsafe to repeat.
• Publishing events outside the database transaction (the dual-write problem).
• Using two-phase commit across services and creating fragile coupling.

Must-know points

• Majority (quorum) = more than half; a cluster of N tolerates (N − 1) ÷ 2 failures, so use odd sizes like 3 or 5.
• Raft roles: follower, candidate, leader. Terms stop an old leader from acting.
• Randomised election timeouts avoid split votes.
• Used for: leader election, distributed locks, configuration and metadata.
• Don't build your own: use etcd, ZooKeeper or a managed service.

Common mistakes

• Running an even number of nodes.
• Thinking the smaller side of a partition can still accept writes.
• Building your own consensus instead of using a tested system.

Must-know points

• Never store plain passwords: use a slow, salted hash (bcrypt, scrypt, Argon2).
• Session cookies (state kept on the server, easy to revoke) or JWTs (stateless, hard to revoke).
• OAuth 2.0 = delegated authorisation; OpenID Connect = login and identity on top of it.
• Authorisation models: role-based (RBAC) or attribute-based (ABAC). Check on every request, on the server.
• Defence in depth: TLS, input validation, rate limiting, least privilege, audit logs.
• Common attacks: SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), credential stuffing.

Common mistakes

• Checking permissions only in the user interface.
• Long-lived JWTs that can't be revoked.
• Storing passwords with a fast hash (MD5, SHA-256) or without a salt.
• Secrets committed to Git.

Must-know points

• Encapsulation: private state, with public methods that keep it valid.
• Abstraction: interfaces and abstract classes describe what, not how.
• Inheritance: an 'is-a' relationship; reuses code but creates tight coupling.
• Polymorphism: one interface, many implementations; replaces long if/else chains on type.

Common mistakes

• Public fields that anyone can set to invalid values.
• Using inheritance just to reuse a few lines of code.
• Type checks (if isinstance …) where polymorphism would do.

Must-know points

• 'Is-a' → maybe inheritance. 'Has-a' → composition.
• Composition lets you change behaviour at runtime and test with fakes.
• Program to an interface, not to an implementation.
• Dependency injection: pass collaborators in; don't create them inside the class.

Common mistakes

• Using inheritance for 'has-a' relationships (a Car extends Engine).
• Creating collaborators inside the class instead of passing them in.

Must-know points

• 'A reason to change' usually means a different person or team asking for changes.
• Warning signs: huge classes, many unrelated imports, methods that never use each other's data.
• The result: smaller classes that are easier to test.

Common mistakes

• Splitting by the number of methods instead of by reason to change.
• Creating dozens of tiny classes that are always changed together.

Must-know points

• Replace 'switch on type' with polymorphism.
• Strategy, Decorator and plug-in designs all follow this principle.
• Protects tested code from new changes.

Common mistakes

• Adding abstractions for variations that will never happen.
• Still having to edit one central if/else to create the new class. Use a registry or configuration instead.

Must-know points

• Subclasses keep the parent's contract: the same or looser inputs, the same or stronger outputs.
• Warning signs: overridden methods that throw 'not supported', or isinstance checks in calling code.
• Fix: a better abstraction, such as a Shape interface with area().

Common mistakes

• Overriding a method just to throw 'not supported'.
• A subclass that needs more specific input than its parent accepts.

Must-know points

• Warning sign: methods that raise NotImplementedError or do nothing.
• Split interfaces by what each client needs (role interfaces).
• Works hand in hand with single responsibility.

Common mistakes

• One interface per method everywhere, which fragments the design.
• Keeping the fat interface 'for convenience'.

Must-know points

• Depend on interfaces; inject the implementations (dependency injection).
• Makes testing easy with fakes and mocks.
• Lets you swap infrastructure, like the database or email provider, with no change to business logic.
• Dependency inversion is the principle; dependency injection is a technique for achieving it.

Common mistakes

• An interface that copies one vendor's API exactly, so the abstraction leaks.
• Creating dependencies inside methods 'just this once'.

Must-know points

• Composition (filled diamond): the owner controls the part's lifetime.
• Aggregation (empty diamond): shared parts that can exist alone.
• Inheritance: a line with an empty triangle. Realisation: a dashed line with an empty triangle.
• In an interview, show only the important classes and methods.

Common mistakes

• Drawing every getter and setter.
• Spending 20 minutes on the diagram and leaving no time to code.

Must-know points

• Critical section: code that touches shared data; protect it with a lock.
• Race condition: read–modify–write without protection.
• Deadlock needs four conditions; break 'circular wait' by always taking locks in the same order, or use timeouts.
• Across several servers, an in-program lock isn't enough: use database transactions or a distributed lock.
• Prefer thread-safe queues and data that never changes, where you can.

Common mistakes

• Locking only the write, instead of the whole read-check-write.
• Holding a lock while doing slow work, like a network call.
• Taking locks in different orders in different places, which causes deadlock.

Must-know points

• Use it for a truly single, shared resource.
• Make creation thread-safe (double-checked locking), or create the instance eagerly.
• In Python, a module is already a natural singleton.
• Often criticised as global state; prefer injecting one shared instance.

Common mistakes

• Using Singleton for things that aren't truly single, like 'the current user'.
• Hidden dependencies: code reaches for the global instead of receiving what it needs.

Must-know points

• Use it when the exact class depends on input or configuration.
• Factory Method: one product, a method decides. Abstract Factory: families of related products.
• A registry dictionary avoids long if/else chains.
• The 'simple factory' (one create function) is the usual interview version.

Common mistakes

• A factory that's just a giant if/else edited for every new type.
• Factories for objects that only ever have one type.

Must-know points

• Use it for objects with many optional settings, or multi-step construction.
• Fluent style: each step returns the builder, so calls can be chained.
• Validate in build(); the finished object can then be unchangeable.
• In Python, keyword arguments with defaults often solve the same problem; in Java, Builder is very common.

Common mistakes

• Letting the half-built object escape before build() is called.
• Using a builder for objects with only two or three fields.

Must-know points

• Use it to plug in third-party or legacy code without changing your own interface.
• Prefer wrapping an object (object adapter) over inheriting from it (class adapter).
• Keeps vendor-specific code in one place, so switching vendors is easy.

Common mistakes

• Letting the third-party's types leak through the adapter into business code.
• Losing error details during the conversion.

Must-know points

• Same interface as the wrapped object, so wrappers can stack.
• Avoids an explosion of subclasses for every feature combination.
• Follows open/closed: add features without editing classes.
• Python's @ syntax is a related idea for functions.

Common mistakes

• Wrappers that change what the method means, rather than just adding to it.
• Wrapping in the wrong order (for example, caching errors).

Must-know points

• Simplifies a subsystem; the subsystem stays available for advanced use.
• Reduces coupling between callers and many classes.
• Keep it thin: coordination, not business logic.

Common mistakes

• Putting business rules into the facade.
• Forcing every caller through the facade even when they need fine control.

Must-know points

• Replaces 'which algorithm?' conditionals with polymorphism.
• Strategies can be swapped at runtime.
• In Python, plain functions can be strategies.
• Very common in LLD answers: pricing, payment, parking fees.

Common mistakes

• Strategies that need lots of the context's private data (a sign the interface is wrong).
• Creating strategy classes for one fixed algorithm.

Must-know points

• Decouples the publisher from its listeners.
• Subscribers can be added and removed at runtime.
• Watch for memory leaks (forgotten subscribers) and slow or failing subscribers.
• At system level, the same idea becomes pub/sub with a message broker.

Common mistakes

• Never unsubscribing, which leaks memory.
• Letting one subscriber's error stop the others from being notified.
• Relying on subscribers being called in a particular order.

Must-know points

• Decouples whoever sends the request from whichever handler deals with it.
• Handlers can be added, removed or reordered.
• Make sure something handles the end of the chain.
• Middleware pipelines are the everyday example.

Common mistakes

• No default at the end, so requests disappear silently.
• Very long chains that are hard to trace.

Must-know points

• Each state class handles the events that are valid in that state.
• Transitions are explicit; invalid actions get a clear response.
• Start by drawing a state diagram.
• A cousin of Strategy, but here the object changes its own behaviour.

Common mistakes

• States that know too much about each other.
• Forgetting some events in some states (like cancel while dispensing).

The design, step by step

1. Entry: a vehicle arrives → the assignment strategy finds a free spot that fits → the spot is marked taken in one atomic step → a ticket is issued.
2. Exit: scan the ticket → the pricing strategy works out the fee from the time parked → payment → the spot is freed.
3. Display boards subscribe to spot changes (Observer) and update their counts.

Deep dives

• Concurrency: two gates assigning the same spot. Use a lock (per floor, or for the whole lot), or an atomic compare-and-set on the spot.
• Fit rules: can a bike use a car spot when bike spots are full? Decide, and say it out loud.
• Lost ticket: charge the maximum daily fee.
• Extensibility: electric-car charging spots become a new spot type with their own pricing strategy.

Common mistakes

• Putting pricing logic inside Ticket or Vehicle.
• Ignoring two gates acting at the same moment.
• Vehicle subclasses that override lots of behaviour instead of just declaring their size.

The design, step by step

1. Each lift serves its stops with the LOOK algorithm: keep going in one direction, serving stops on the way, then turn around — like a lift operator sweeping up and down.
2. A controller assigns each hall call to the best lift: idle and near, or already moving towards that floor in the same direction.
3. Each lift has a state machine that enforces safety: doors must be closed before moving.

Deep dives

• Dispatch cost = distance + stops on the way + a penalty for the wrong direction.
• Peak times: in the morning rush, send idle lifts back to the ground floor.
• Concurrency: requests arrive from many buttons at once, so use a thread-safe queue into the controller.
• Overload sensor: the doors stay open.

Common mistakes

• First-come, first-served scheduling.
• No state machine, so 'moving with the doors open' is possible.
• Over-complicating the dispatch algorithm before the basics work.

The design, step by step

1. Add an expense: validate the split (it sums to the total) → each participant now owes the payer their share.
2. Keep one net balance per user: positive means they're owed money, negative means they owe.
3. Simplify debts: repeatedly match the biggest debtor with the biggest creditor until everyone is at zero.

Deep dives

• Store money as whole pence (or Decimal), never as float.
• Rounding: £10 split three ways is 334 + 333 + 333 pence; give the extra penny to someone in a fixed, fair way.
• The greedy simplification settles n people in at most n − 1 payments.

Common mistakes

• Floats for money.
• Splits that don't add up to the total.
• Losing the leftover pence when rounding.

The design, step by step

1. Idle → select an item → ItemSelected → insert money → HasMoney (once paid ≥ price) → Dispensing → give change → Idle.
2. Cancel while in ItemSelected or HasMoney → refund → Idle.
3. An item with no stock left → SoldOut for that item.

Deep dives

• Change-making: the greedy method works for UK coins when you have plenty of each, but with limited coins it can fail even when exact change is possible (60p with one 50p and three 20p coins). Use dynamic programming, or refuse the sale.
• Keep money in whole pence.
• Power cut mid-sale: record the transaction before dispensing, so it can be recovered.

Common mistakes

• An if/else on a status string in every method.
• Taking money for an item that's sold out.
• Assuming change can always be made.

The design, step by step

1. A hash map finds a key's node in O(1).
2. A doubly linked list keeps items in order of use: most recent at the front, least recent at the back.
3. get: move the node to the front. put: update and move to the front, or insert at the front and remove the back node if over capacity.

Deep dives

• Dummy head and tail nodes remove the edge cases.
• Thread safety: one lock around get and put (or several locks for parts of the cache).
• In Python, OrderedDict with move_to_end does the same in a few lines; know both versions.

Common mistakes

• A singly linked list, which can't remove a node in O(1).
• Forgetting to update the order on get.
• Forgetting to delete the evicted key from the dictionary.

The design, step by step

1. An incoming buy order fills against the cheapest sell orders while their price is at or below the buy price, oldest first at each price.
2. Any quantity left over rests in the book.
3. Each stock's book is processed by one thread, in sequence, fed by a queue, so no locks are needed inside the book.

Deep dives

• Price-time priority: better price first; at the same price, the earliest order first.
• One thread per stock gives determinism and avoids locks; parallelism comes from different stocks.
• Log every order before processing it, so the book can be rebuilt by replay after a crash.

Common mistakes

• Ignoring time priority at the same price.
• Using locks inside the matching loop instead of processing in sequence.
• Floats for prices.

The design, step by step

1. Write: the API generates a unique code and stores code → long URL.
2. Read: GET /{code} → check the Redis cache → on a miss, read the database → redirect.
3. Code generation: a distributed counter (ID ranges per server) encoded in Base62, or a hash of the URL cut to 7 characters, with collision checks.
4. Very popular links can also be cached at the edge.

Deep dives

• Counter + Base62: no collisions. Each server reserves a block of IDs from a coordinator, so servers don't fight over one counter.
• Hashing: the same URL always gets the same code (no duplicates), but collisions need check-and-retry.
• 301 (permanent; browsers cache it, so less load but no analytics) or 302 (temporary; every click reaches you, so analytics work).
• Analytics: log each click to a queue and aggregate in the background.

Common mistakes

• Hashing the URL without handling collisions.
• No caching, for a workload that's 100 times more reads than writes.
• Using 301 redirects, then wondering why the analytics are empty.

The design, step by step

1. The limiter runs as middleware in the API gateway.
2. Rules are loaded from a config store and cached locally.
3. Counters live in a Redis cluster and are checked and updated atomically with a Lua script (or INCR plus EXPIRE for fixed windows).
4. Over the limit → 429 with Retry-After.

Deep dives

• Race conditions: two servers reading and writing the same counter at once → use atomic Redis operations or a Lua script.
• Multiple regions: a limit per region (slightly inaccurate) or a global store (slower).
• Redis failure: fail open, with a local in-memory limit as a backup.
• Hot clients: spread counters across Redis nodes by client ID.

Common mistakes

• Read-then-write counters with no atomicity.
• Limiting per server instead of across all servers.
• No answer to 'what if Redis is down?'.

The design, step by step

1. A notification service checks preferences and rate limits, and fills in the template.
2. It puts messages onto separate queues per channel (push, SMS, email) and per priority (passcodes ahead of marketing).
3. Channel workers call the providers (Apple and Google push services, an SMS gateway, an email service).
4. Retries with backoff; repeated failures go to a dead-letter queue; every status is recorded in a log.

Deep dives

• De-duplication: an idempotency key per notification, so retries don't send twice.
• Separate priority queues, so a marketing blast never delays a passcode.
• Provider failover: a second SMS provider.
• A per-user rate limit, so nobody gets spammed.

Common mistakes

• Sending inside the user's request.
• One queue where marketing messages block passcodes.
• Retries without idempotency, so users get duplicates.

The design, step by step

1. Each client keeps a WebSocket connection to a chat gateway server.
2. Sending: gateway → chat service gives the message a time-ordered ID and stores it, then routes it.
3. Routing: look up the recipient's gateway in Redis and push to it; if they're offline, keep it stored and send a push notification.
4. Groups: send a copy to each member (small groups), or have members fetch it (very large groups).
5. Receipts and presence are small events that travel the same path.

Deep dives

• Ordering: a sequence number per conversation; clients sort by it.
• Retries without duplicates: the client creates a message ID, so resending is idempotent.
• Presence: heartbeats with a TTL in Redis; don't broadcast every status change to everyone.
• End-to-end encryption: the server only ever stores ciphertext.

Common mistakes

• Polling at scale.
• Forgetting offline users.
• No plan for ordering or duplicates.

The design, step by step

1. Fan-out on write (push): when someone posts, add the post ID to each follower's feed list. Reads are fast.
2. Fan-out on read (pull): build the feed at request time from the followed users' recent posts. Writes are cheap; reads are slow.
3. Hybrid: push for normal users; for celebrities with millions of followers, pull their posts at read time and merge.
4. Post content comes from a cache and media from a CDN; a ranking service can reorder the feed.

Deep dives

• The celebrity problem: pushing to 50 million followers for every post is far too expensive → use the hybrid.
• Each user's feed list keeps only the latest few hundred post IDs.
• Skip pushing to inactive users; build their feed when they log in.
• Ranking: gather candidates → score them with a model → re-rank for variety.

Common mistakes

• Push-only fan-out that ignores celebrities.
• Storing whole posts in every feed instead of post IDs.
• Offset pagination on a feed that keeps changing.

The design, step by step

1. Upload: the client gets a pre-signed URL and uploads in parts straight to object storage.
2. An event on a queue triggers transcoding workers, which cut the video into short segments and encode several resolutions and bitrates (a graph of tasks).
3. The outputs go to object storage, with a manifest (HLS or DASH) listing the segments for each quality.
4. Playback: the player fetches the manifest and segments from a CDN and switches quality as bandwidth changes (adaptive bitrate).
5. Video details live in a database with a cache; view counts are aggregated in the background.

Deep dives

• Adaptive bitrate: small segments (2–10 seconds) at several qualities.
• Transcoding runs in parallel per segment, with retries per task.
• Popular videos sit on the CDN; rarely watched ones are served from origin.
• Resumable uploads for big files.

Common mistakes

• Streaming from your own servers instead of a CDN.
• Transcoding inside the upload request.
• One quality for every device and connection.

The design, step by step

1. A location service takes driver updates and keeps only the latest position in an in-memory geospatial index (geohash cells, for example Redis GEO).
2. A matching service searches nearby cells, ranks drivers by arrival time, and offers the trip to one driver at a time with a timeout.
3. The offered driver is locked with an atomic status update, so they can't be double-booked.
4. A trip service tracks the trip's state; pricing (including surge) and payment services handle the money.

Deep dives

• Geohash: nearby places share a prefix; search the rider's cell and its neighbours.
• Location updates are short-lived: keep only the latest in memory, and stream the history to cheap storage for analytics.
• Surge pricing from supply and demand in each area.
• Driver assignment uses an atomic compare-and-set.

Common mistakes

• Scanning every driver for every request.
• Saving every location update permanently in the main database.
• Offering one ride to several drivers without locking.

The design, step by step

1. The payment service receives the request with an idempotency key; a unique constraint in the database blocks duplicates.
2. It creates a PENDING payment record, then calls the payment provider. The provider handles the card details, so you never store raw card numbers.
3. The provider's result (response or webhook) updates the status, and balanced double-entry ledger rows are written in the same transaction.
4. The order service is told through an outbox event.
5. A nightly reconciliation job compares the ledger with the provider's settlement files.

Deep dives

• Idempotency keys plus unique constraints make every retry safe.
• Double-entry ledger: every movement is a debit and an equal credit; balances are sums; entries are never edited, only added (corrections are new entries).
• Provider timeout: the result is unknown, so retry with the same idempotency key or ask the provider for the status before doing anything else.
• Store money as whole minor units (pence) together with the currency.

Common mistakes

• Retrying a timed-out charge with a brand-new request.
• Floats for money.
• Updating balances in place, with no ledger history.

The design, step by step

1. Serving: an in-memory trie (or a prefix → top-k map in Redis); a lookup just walks the prefix.
2. Data pipeline: log searches → count them every hour or day → rebuild the trie → swap the new one in.
3. Client: wait for a short pause in typing before asking, and cache recent prefixes; cache common prefixes at the edge.
4. Split the trie across servers by prefix when it gets too big.

Deep dives

• Store the top-k completions at every node, so a query never has to search a whole subtree.
• Freshness: trending terms through a streaming pipeline, with older counts decaying over time.
• Filter out offensive suggestions.
• Personalisation: blend global suggestions with the user's own history.

Common mistakes

• Searching the whole subtree on every keystroke.
• Rebuilding the trie inside the serving path.
• Sending a request on every keystroke, with no pause.

The design, step by step

1. Score updates go to the game service, which saves them durably and updates a Redis sorted set.
2. Top N: ZREVRANGE 0 N−1. A player's rank: ZREVRANK. Both run in logarithmic time.
3. A separate sorted set per period (daily, weekly), with expiry.
4. At very large scale: split by score range, or give approximate ranks.

Deep dives

• Sorted sets are skip lists: logarithmic updates and rank lookups.
• Ties: fold a timestamp into the score, so whoever reached it first ranks higher.
• Rebuild Redis from the database after a failure.

Common mistakes

• Recalculating ranks with SQL on every request.
• No durable copy, so a Redis restart loses the scores.
• Ignoring ties.

The design, step by step

1. Clients, or a proxy, route each key to a node with consistent hashing and virtual nodes.
2. Each node: an in-memory hash table with LRU eviction and TTL expiry.
3. Each shard has a replica for failover.
4. Cluster membership comes from a configuration service, or nodes gossip with each other.

Deep dives

• Hot keys: replicate them, or add a small local cache inside the app.
• Cache stampede: let one request rebuild a key while the others wait.
• Node failure: promote the replica; the misses fall on the database, so warm the cache gradually.
• Optional persistence (snapshots or an append-only file in Redis).

Common mistakes

• hash % N routing, which causes mass misses whenever servers change.
• No plan for hot keys.
• No warm-up after a failure.

The design, step by step

1. Ingestion: parse → clean → split into chunks with some overlap → embed → store in a vector store with permission metadata, triggered whenever a document changes.
2. Query: rewrite the question using the conversation → hybrid retrieval (vectors plus keywords), filtered by the user's permissions → re-rank → build a prompt with the top chunks → the LLM streams an answer with citations.
3. Guardrails: check retrieved text for prompt injection, and check the output.
4. Observability: trace every step; run evaluations on a golden set; collect user feedback.

Deep dives

• Permissions are enforced in the retrieval filter; never rely on the LLM to hide data.
• Chunking and re-ranking usually bring the biggest quality gains.
• Evaluation: retrieval recall@k plus answer faithfulness on a golden set, run as regression tests for every change.
• Cost and latency: cache frequent answers; send easy questions to a smaller model.

Common mistakes

• No evaluation, so changes are judged by feel.
• Handling permissions by asking the LLM not to reveal things.
• Never updating the index when documents change.

The design, step by step

1. Two stages. Candidate generation retrieves about 500–1,000 items quickly (embedding similarity with approximate nearest-neighbour search, items often bought together, popular items). Ranking then scores those candidates with a richer model using user, item and context features.
2. Re-ranking applies business rules: variety, freshness, removing items already seen.
3. Models train offline on logged interactions; features come from a feature store, defined the same way for training and serving.
4. Online A/B tests measure the real impact of every change.

Deep dives

• Cold start: new users get popular and contextual items; new items use content features.
• Feedback loops and popularity bias: add some exploration.
• Training-serving skew: one feature definition used both offline and online.
• Metrics: offline (recall@k, NDCG) and online (click-through, watch time, retention).

Common mistakes

• Scoring every item with a heavy model on every request.
• Judging success only by offline metrics.
• Ignoring the cold-start problem.

The design, step by step

1. Transaction → scoring service: fetch real-time features (how many transactions in the last 10 minutes, distance from usual location, device) and historical features → rules engine plus an ML model (often gradient-boosted trees) → decision using thresholds.
2. A streaming pipeline (Kafka plus a stream processor) keeps the windowed counts and sums up to date.
3. Every decision and its features are logged; fraud labels arrive later (chargebacks) and are joined for retraining.
4. A case-management tool for fraud analysts.

Deep dives

• Class imbalance: choose the precision–recall trade-off from the cost of fraud versus the cost of blocking good customers.
• Delayed, noisy labels, and fraudsters changing tactics (drift): monitor and retrain often.
• If the model service is down or slow, fall back to rules only.
• Point-in-time correct features, so no future information leaks into training.

Common mistakes

• Using accuracy as the metric.
• Features calculated with information from the future.
• No fallback when the model service fails.

The design, step by step

1. A gateway handles authentication, quotas, rate limits and routing to a pool of servers per model.
2. Model servers (vLLM-style) use continuous batching and a paged KV cache to keep the GPUs busy.
3. GPU pools scale automatically on queue length and latency.
4. Responses stream back through the gateway; prefix caching reuses work for repeated system prompts.
5. Metrics: time to first token, tokens per second, GPU utilisation, errors, and usage per team.

Deep dives

• Prefill (reading the prompt) and decode (generating one token at a time) have different bottlenecks.
• Continuous batching adds new requests between decode steps instead of waiting for a whole batch to finish.
• Quantised, smaller or distilled models for cheaper tiers; speculative decoding for speed.
• Overload: a bounded queue, and dropping low-priority traffic first.

Common mistakes

• Handling one request at a time on an expensive GPU.
• Ignoring KV-cache memory when planning capacity.
• No per-team quotas, so one team can starve the others.

The design, step by step

1. An orchestrated pipeline (for example Airflow): ingest → validate the data → build features → train → compare with the current model → register.
2. A feature store: one definition per feature, an offline store for training (with point-in-time correct joins) and an online store for fast serving.
3. Deploy with shadow or canary releases; monitor data drift, prediction drift and business metrics.
4. Retrain on a schedule, or when drift is detected.

Deep dives

• Training-serving skew: compute each feature once and use it in both places.
• Point-in-time joins stop future data leaking into training.
• Data validation catches broken upstream data before it trains a bad model.
• Lineage: every model links to its data version, code commit and settings.

Common mistakes

• Different feature code in training and in serving.
• No data validation.
• No way to roll back a bad model.