Practice mode
Practice
221 topics come with explain-without-notes and implement prompts (18 LLD problems and 39 HLD systems among them). The syllabus is a workflow, not a wiki — every item below ends in you doing something with the file closed.
Pick a drill at random
Let the syllabus choose your next 25 minutes.
Topic S.1 — Clients, Servers & the Life of a RequestEvery system is programs talking to other programs over a network. A client asks, a server answers. Follow one click from a browser to a database and back, and every later topic is a variation of this trip. code java implement explainTopic S.2 — APIs, JSON & ContractsAn API is the menu a server offers: which requests it accepts and what it returns. Agreeing on that contract, usually HTTP + JSON, is what lets teams, apps, and services work together without reading each other's code. code implement explainTopic S.3 — Where Data Lives: Memory, Disk, Databases & CachesData sits in different places that trade speed for size and safety: CPU cache, RAM, SSD, databases, remote services. Knowing roughly how fast each is explains why caches exist and why every design tries to avoid slow trips. code implement explainTopic S.4 — From 1 User to 1 Million: The Scaling StoryThe single most useful story in system design: start with one server, then add each building block only when a real problem appears. Every later phase is a zoom-in on one step of this journey. code implement explainTopic S.5 — The Vocabulary: Reading Any Design DiagramFifteen words cover most of what you'll hear in design discussions: latency, throughput, availability, consistency, scalability, SPOF, replication, sharding, cache, queue, idempotency, and more. Learn them once with plain definitions. code implement explain
0.1What is System Design?System design is the practice of turning a vague product idea into a concrete set of components, their interactions, and the data that flows through them — while accounting for scale, failure, and cost. java implement explain0.2LLD vs HLDLow-level design is the code view (classes, interfaces, patterns, relationships); high-level design is the system view (services, databases, queues, scaling). Both matter, and interviews start at HLD and zoom into LLD. java implement explain0.3Functional vs Non-functional RequirementsFunctional requirements say what the system does; non-functional requirements say how well it does it. Non-functional requirements are where system design actually happens. code java implement explain0.4Trade-offsThe most senior signal in an interview is the ability to answer 'why this and not that?' Every architectural decision is a trade-off; interviews test whether you can name the thing you gave up. java implement explain0.5Numbers Every Engineer Should KnowDesign decisions are only as good as the numbers behind them. Memorize a small set of latency, throughput, and size figures so you can size any system in your head during an interview. code java implement explain0.6The 45-Minute Interview FrameworkInterviewers grade the process as much as the design. A disciplined time budget keeps you from spending 30 minutes on requirements or reaching the deep dive with no time left. code implement explain
1.1OOPFour pillars (encapsulation, inheritance, polymorphism, abstraction) plus the relationship vocabulary (composition, aggregation, association, dependency) that LLD answers are built from. code java implement explain1.2SOLIDFive principles that keep a codebase changeable: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. For interviews, connect each to the production pain it prevents. code java implement explain1.3UML / Class RelationshipsInterviews rarely ask you to draw formal UML, but the relationship vocabulary (1:1, 1:N, N:N, association, aggregation, composition, inheritance, dependency) is used constantly to describe a class diagram out loud. java implement explain1.4Abstraction DesignChoosing the right abstraction — interface vs abstract class vs concrete class — and the two patterns that power most LLD answers (strategy and factory). code java implement explain1.5Domain Modeling EssentialsEntities, value objects, invariants, immutability, and a deliberate error model. Most LLD bugs come from anemic data bags that let invalid state exist, not from missing patterns. code java implement explain
Creational 1 — FactoryCentralize object creation behind one method so callers depend on the created type's contract, not its construction logic. code java implement explainCreational 2 — Abstract FactoryProvides an interface for creating a family of related objects without specifying their concrete classes — e.g. a UI kit that produces LightButton + LightDialog together. code java implement explainCreational 3 — BuilderConstruct complex objects step-by-step with readable, fluent calls — especially when there are many optional or immutable fields. code java implement explainCreational 4 — PrototypeClone an existing instance instead of re-running expensive construction. Rare in interviews — know the intent, not the ceremony. code java implement explainCreational 5 — SingletonOne instance per JVM, with a globally reachable accessor. Interviews love it because naive implementations break under concurrency. code java implement explainStructural 1 — AdapterMake an incompatible interface look like the one your client expects — a translator between contracts. code java implement explainStructural 2 — DecoratorWrap an object to add behavior at runtime, stackable without touching the original class. code java implement explainStructural 3 — FacadeOne simplified entry point that hides a messy subsystem of many classes. code java implement explainStructural 4 — ProxyA stand-in that controls access to the real object: lazy init, access control, caching, remote calls. code java implement explainStructural 5 — CompositeTreat individual objects and groups of objects uniformly — a tree where leaves and nodes share an interface. code java implement explainStructural 6 — BridgeDecouple an abstraction from its implementation so both can vary independently — avoids the 2D class explosion. code java implement explainStructural 7 — FlyweightShare the intrinsic (immutable, common) part of many fine-grained objects and pass the extrinsic (per-use) part in, so a million objects cost the memory of a few hundred. code java implement explainBehavioral 1 — StrategyEncapsulate a family of algorithms behind one interface and swap them at runtime — the single most used pattern in LLD interviews. code java implement explainBehavioral 2 — ObserverOne subject notifies many listeners when its state changes — the publish/subscribe idea in-process. code java implement explainBehavioral 3 — CommandWrap a request (and its receiver) into an object — enables undo/redo, queuing, logging, and macros. code java implement explainBehavioral 4 — StateAn object changes behavior when its state changes — state logic moves from if/else soup into per-state classes. The vending machine pattern. code java implement explainBehavioral 5 — Template MethodDefine the skeleton of an algorithm in a base class, let subclasses fill in specific steps — inversion of control inside one class hierarchy. code java implement explainBehavioral 6 — Chain of ResponsibilityPass a request along a chain of handlers; each handler decides to process it or pass it on. Middleware, filters, validators. code java implement explainBehavioral 7 — IteratorProvide sequential access over a collection without exposing its internals. Mostly baked into Java today — nested iterators (tree walks, pagination) still show up. code java implement explainBehavioral 8 — MediatorCentralize interactions between many objects so they talk to one mediator instead of each other — star topology. code java implement explainBehavioral 9 — MementoSave a snapshot of an object's state so you can restore it later, without exposing its private fields. Think 'save game' in a video game. code java implement explainBehavioral 10 — VisitorAdd new operations to a group of classes without changing those classes. The operation 'visits' each object and does the right thing for its type. code java implement explain
3.1Requirement AnalysisGiven a problem like Parking Lot, you must enumerate the actors, objects, rules, and edge cases before any code — this is the difference between a designer and a coder in an interview. code java implement explain3.2Identify EntitiesNouns become entities, verbs become operations, rules become business logic. A disciplined translation from English to classes. code java implement explain3.3Responsibility AssignmentThe single most important LLD skill: deciding which class owns which behavior — and keeping responsibilities from bleeding across classes. java implement explain3.4ExtensibilityDesign so a new variation — payment method, vehicle type, pricing rule, storage, channel — does not rewrite the system. code java implement explain3.5Dependency InjectionThe binding that holds LLD designs together: interface → implementation → constructor injection → Spring bean. It is the mechanism that makes strategy, port/adapter, and testability real. code java implement explain3.6Testing Your LLDA design is only proven when tests show it works and stays easy to change. A few sharp unit tests for the rules and edge cases are what separate 'it compiles' from 'I'd ship this'. code java implement explain3.7The LLD Interview, Start to FinishPut Phases 1–3 together into one repeatable 45-minute script: requirements → entities → class diagram → core code → concurrency → extensions. Use it for every problem in Phase 4. code implement explain
Problem 4.1 — Parking LotThe canonical LLD problem. It exercises composition, the Factory pattern, pricing strategies, ticketing, and concurrency around spot assignment. code java implement explainProblem 4.2 — Vending MachineThe classic State-pattern problem: same actions behave differently depending on idle/has-money/dispensing states. code java implement explainProblem 4.3 — ATMState + transaction handling + cash management + authentication. Districts it from vending machine with authentication, session and ledger concerns. code java implement explainProblem 4.4 — Library ManagementEntities, borrow/return flows, fine calculation and search — the 'clean CRUD with rules' LLD problem. code java implement explainProblem 4.5 — ElevatorState + scheduling + concurrency + request handling. The harder LLD: multiple elevators moving between floors with internal and external requests. code java implement explainProblem 4.6 — SplitwiseExpense splitting with strategies and settlement math — exactly one map of balances and a strategy per split rule. code java implement explainProblem 4.7 — Tic-Tac-ToeA tight game-engine problem where strategy, board state, players and win-checking must stay decoupled and extensible. code java implement explainProblem 4.8 — ChessThe inheritance-vs-composition battle ground: piece movement, game state, rules, castling, check/checkmate. code java implement explainProblem 4.9 — BookMyShow (Ticket Booking)Seat locking, show/seat modeling, pricing by category, and the invalidation of stale holds — a Level-3 problem that combines LLD and concurrency. code java implement explainProblem 4.10 — Food Delivery (LLD)Order lifecycle state machine + delivery-partner matching + notifications — the LLD version of the classic HLD. code java implement explainProblem 4.11 — Ride Booking (LLD)Driver/rider matching, pricing (surge), trip lifecycle and the 'find nearest available driver' core. code java implement explainProblem 4.12 — Notification System (LLD)The factory + strategy + observer showcase: channels, templates, fan-out and retries. code java implement explainProblem 4.13 — Payment System (LLD)Where correctness is non-negotiable: payment states, idempotency keys, double-charge prevention, and the integration-seam problem. code java implement explainProblem 4.14 — File Storage System (LLD)Storage abstraction, naming, chunking metadata, and access control — the LLD core under Dropbox/Drive HLDs. code java implement explainProblem 4.15 — Rate Limiter (LLD)The bridge problem between LLD and HLD: algorithms, concurrency-safe counters, and where Redis takes over. Revisit it in Phase 12 for the distributed version. code java implement explainProblem 4.16 — LRU CacheThe most-asked LLD warm-up: `get` and `put` in O(1) with least-recently-used eviction, built from a hash map plus a doubly linked list, then made thread-safe and generic. code java implement explainProblem 4.17 — Logging FrameworkDesign a mini SLF4J/Logback: log levels, multiple appenders (console, file, remote), formatters, per-logger configuration, and asynchronous writing that never blocks the application. code implement explainProblem 4.18 — In-Memory Pub/Sub SystemTopics, publishers, and subscribers in one process: fan-out delivery, per-subscriber ordering, slow-consumer isolation, and offsets for replay, a small model of Kafka and Redis Pub/Sub. code implement explain
5.1Java Concurrency PrimitivesThread, Process, Runnable, Callable, Future — the units and handles of concurrent work. code java implement explain5.2Synchronization and Lockssynchronized, volatile, Lock, ReentrantLock, ReadWriteLock — the mechanisms, and critically, what each one is (not) for. code java implement explain5.3Concurrent Data Structures / AtomicsAtomicInteger, AtomicLong, ConcurrentHashMap, BlockingQueue — the toolbox that removes most manual locking. code java implement explain5.4Thread PoolsExecutorService, ThreadPoolExecutor, its queue, worker threads and rejection policy — the operational half of concurrency. code java implement explain5.5Race ConditionsTwo threads interleave on shared state and the result depends on timing — the bug class every LLD question secretly tests. code java implement explain5.6DeadlocksThread A holds lock 1 and wants lock 2; thread B holds lock 2 and wants lock 1 — both wait forever. code java implement explain5.7Locks vs AtomicsThe performance/readability trade: when to use synchronized/locks vs CAS atomics. java implement explain5.8Producer / ConsumerThe fundamental async pattern: producers enqueue, consumers dequeue — decoupling, back-pressure, and rate mismatch handling. code java implement explain5.9Thread-safe SingletonPhase 2's singleton, now graded under concurrency: the four safe forms and why naive lazy init crashes with two threads. java implement explain5.10Concurrent Rate LimiterApplying everything in this phase to the limiter: per-key state, atomic claims, and the shared-map granularity decision. java implement explain5.11Concurrent CacheBuilding the Phase 10 cache-aside in-process first: thread-safe read/write, single-flight, and eviction under concurrency. code java implement explain
6.1Internet BasicsClient, server, DNS, IP, port — the five components behind every request you've ever made. code java implement explain6.2HTTPThe verbs, headers, body, cookies and status codes that every API contract is written in. code java implement explain6.3HTTPS / TLSTLS wraps HTTP: certificates prove identity, the handshake agrees on keys, and everything after is encrypted. code java implement explain6.4TCP vs UDPReliable ordered streams vs fast lossy datagrams — and why video/real-time apps pick the lossy one. code java implement explain6.5WebSocketA persistent, bidirectional, message-oriented connection for low-latency push — chat, live cursors, trading feeds. code java implement explain6.6RESTThe dominant API style: resources + verbs + status codes + statelessness. java implement explain6.7gRPCRPC with a schema, HTTP/2 multiplexing, and binary protobuf payloads — the internal-to-service favorite. code java implement explain6.8Long PollingThe HTTP-compatible trick for push-ish: hold the response open until there's news or a timeout. code java implement explain6.9SSE (Server-Sent Events)One-way server→client push over a single long-lived HTTP connection — the cheap realtime win. java implement explain6.10DNS Resolution FlowThe exact path a name takes to become an IP — and the trip points where HLDs get slow or break. code java implement explain
Topic 6B.1 — REST Resource DesignModel your API around resources (nouns) and use HTTP methods as the verbs. Consistent naming, status codes, and error shapes make an API predictable, and predictable APIs get integrated faster and break less. code java implement explainTopic 6B.2 — Pagination, Filtering & Sorting at ScaleAny list can grow to millions of items. Offset pagination is simple but slow and inconsistent at depth; cursor (keyset) pagination is stable and fast. Filtering and sorting must line up with database indexes. code implement explainTopic 6B.3 — Versioning & Evolving APIs Without Breaking ClientsAPIs live longer than the code behind them. Evolve them with additive, backward-compatible changes; when you must break, version explicitly, run both versions, and retire the old one with deprecation notices and data. implement explainTopic 6B.4 — Idempotency Keys, Timeouts & Safe RetriesNetworks fail after the server did the work but before the client heard back. Idempotency keys let clients retry 'create payment' safely; timeouts and retry rules keep one slow dependency from taking everything down. code java implement explainTopic 6B.5 — REST vs GraphQL vs gRPC vs EventsFour ways to shape an API, each best at something: REST for public resource APIs, GraphQL for flexible client-driven queries, gRPC for fast typed service-to-service calls, and events for asynchronous decoupling. code implement explainTopic 6B.6 — Authentication: Sessions, JWT, OAuth 2.0, OIDC & SSOAuthentication answers 'who is calling?'. Sessions and tokens carry that answer between requests; OAuth 2.0 delegates access; OpenID Connect adds login on top; SSO lets one identity provider serve every app. code java implement explainTopic 6B.7 — Authorization: RBAC, ABAC, ReBAC & Multi-Tenant AccessAuthorization answers 'is this caller allowed to do this to that?'. Roles are the simple start, attributes add context, relationships model sharing, and every check must also enforce tenant boundaries. code java implement explain
7.1SQL BasicsTables, primary/foreign keys, indexes, constraints — the vocabulary of relational modeling. code java implement explain7.2Transactions / ACIDAtomicity, Consistency, Isolation, Durability — the contract that makes bank transfers safe and your LLD's ledger correct. code java implement explain7.3Isolation Levels & Read PhenomenaRead Uncommitted → Read Committed → Repeatable Read → Serializable, and the dirty/non-repeatable/phantom reads each level tolerates. code java implement explain7.4IndexesB-Trees, composite and covering indexes, selectivity — how queries actually get fast. code java implement explain7.5JoinsJOIN, LEFT JOIN, GROUP BY, and the cost story: joins are the reason you vertically grow a SQL DB. java implement explain7.6NormalizationSplit data by dependency to kill redundancy and update anomalies: 1NF, 2NF, 3NF. code java implement explain7.7DenormalizationDeliberately duplicating data for read speed — the moment SQL conversations step into system design. java implement explain
8.1ReplicationCopies of the same data on multiple nodes: primary handles writes, replicas serve reads and take over on failure. code java implement explain8.2PartitioningSplitting one logical dataset into smaller slices so each slice can live (and be queried) on its own node. code java implement explain8.3ShardingPartitioning across separate physical databases — the real 'put more money in the machine' of writes. code java implement explain8.4Shard Key SelectionHigh cardinality, even distribution, and alignment with real queries — the three criteria. implement explain8.5Hot PartitionsWhen one shard drowns in traffic while siblings idle — the celebrity/whale/one-tenant problem. implement explain8.6Consistent HashingThe ring-based mapping that makes adding/removing nodes move only a tiny slice of keys — the trick behind Redis clusters, Cassandra, and LB affinity. code java implement explain8.7SQL vs NoSQLThe decision matrix: joins/transactions/flexibility vs scale/schema/consistency — and the honest 'mostly SQL' answer. code java implement explain8.8Document DatabasesMongoDB-style: JSON documents, embedded nesting, flexible schema, secondary indexes, and Atlas-scale ops. java implement explain8.9Key-Value DatabasesDynamoDB/Redis-class stores: O(1) by key, insane scale, and the access patterns that justify them. java implement explain8.10Wide-Column DatabasesCassandra/Bigtable: rows with dynamic columns, partition-key-clustered tables, tuned for planetary write scale. java implement explain
9.1Vertical ScalingBigger machine: more CPU, RAM, disk, network. Simple, finite, and expensive in all the interesting ways. code java implement explain9.2Horizontal ScalingMore machines behind a load balancer — the scalable path that demands statelessness. code java implement explain9.3Stateless ServicesThe principle that makes horizontal scaling, rolling deploys, and instance-juggling boring. implement explain9.4Load BalancersRound Robin, Least Connections, IP Hash, health checks — the front door of every scaled system. code java implement explain9.5CDNCaching static (and some dynamic) content at edge nodes near users — the first latency lever at global scale. code java implement explain9.6Reverse ProxyThe single front door that terminates TLS, compresses, caches, and hides the fleet — Nginx's day job. java implement explain9.7API GatewayThe L7 front door for APIs: routing, auth, quotas, aggregation, and the single integration point for clients. code java implement explain9.8AutoscalingAdd and remove instances by demand signals — the automation that turns capacity into a managed cost. java implement explain9.9Capacity EstimationQPS/RPS, storage, bandwidth, memory — the arithmetic that makes every HLD answer defensible. code java implement explain
10.1Why Cache?Latency and load: the same data read 1000x a second shouldn't hit the DB 1000x. code java implement explain10.2Cache-aside (Lazy Loading)The app checks the cache, loads from the DB on miss, and writes the cache itself — the default strategy. code java implement explain10.3Read-throughThe cache loads from the DB by itself on a miss — the app only ever talks to the cache. java implement explain10.4Write-throughWrites go to the cache first and the cache synchronously writes the store — strong-ish, and always-on freshness. code java implement explain10.5Write-back (Write-behind)Writes land in the cache and flush to the store asynchronously — fast writes, batched persistence, riskier. code java implement explain10.6Eviction Policies: LRU, LFU, TTLWhen the cache is full, what leaves? LRU, LFU, FIFO, random, and how Redis does it. code java implement explain10.7Cache InvalidationThe hardest problem in computer science, at least for interviews: keeping the cache honest after writes. code java implement explain10.8RedisThe de-facto cache/state store: in-memory, single-threaded, rich data types, lua/RDB/AOF, and clustering. code java implement explain10.9Distributed CacheA cache that scales beyond one machine and is shared by the whole fleet — Redis Cluster or a sharded layer. java implement explain10.10Message Queue BasicsProducer → broker → consumer, and why the little words 'decouple', 'buffer', and 'retry' change everything. code java implement explain10.11Kafka Deep DiveThe distributed commit log: topic, partition, offset, consumer group, producer, consumer, replication — the full mental model. code java implement explain10.12Kafka vs Traditional QueueKafka = replayable log; RabbitMQ = smart router. Both are queues to a product manager and different worlds to you. implement explain10.13Delivery SemanticsAt-most-once, at-least-once, exactly-once — the contract between producer and consumer, and where the lies live. code java implement explain10.14RetriesThe last request failed. When do you retry, how hard, and how do retries stop being the retry-storm? java implement explain10.15Dead Letter Queue (DLQ)The parking lot for poison messages: retried N times, failed, and now visible to a human. code java implement explain10.16IdempotencyThe property that makes retries, replays and at-least-once safe: same request → same result, every time. java implement explain
11.1Monolith vs MicroservicesOne deployable vs many — the decision you must be able to justify BOTH ways. implement explain11.2Service BoundariesWhere services get cut — domain events, not CRUD tables — the 'bounded context' idea from DDD. implement explain11.3API Gateway in MicroservicesThe single entry point: routing, auth, rate limiting, and keeping clients independent of service topology. java implement explain11.4Service DiscoveryFinding a service instance by NAME, not IP: registry + heartbeats, or DNS-based resolution. code java implement explain11.5Configuration ManagementConfig that changes without redeploys: externalized, versioned, and environment-aware. java implement explain11.6Synchronous Communication (REST/gRPC)Request/response between services — the default, with gRPC as the high-performance option. code java implement explain11.7Asynchronous Communication (Kafka/Queue)Fire events and let each service react: the decoupling engine behind microservices. java implement explain11.8Circuit BreakerWhen a dependency is failing, stop calling it — fail fast and let it recover. The Resilience4j pattern. code java implement explain11.9Topic 11.9 + 11.10 — Retry, TimeoutTimeouts bound how long a call may take; retries give it another chance — together they form the reliability primitive. java implement explain11.11BulkheadShips have sealed compartments so one leak can't sink the whole ship — same idea for call paths. code java implement explain11.12Distributed TransactionOne business operation spanning multiple services/DBs — where ACID dies and saga is born. code java implement explain11.13SagaA distributed transaction as a sequence of local transactions with compensating actions — the industry answer. code java implement explain11.14Outbox PatternGuarantee the DB write and the event publish happen together — via a table that IS the queue. code java implement explain11.15Idempotency (again, now at fleet scale)Idempotency applied to whole services: keys per logical operation, dedupe stores, and safe replays. java implement explain11.16Distributed LockingMutual exclusion across machines: Redis SETNX, leases, fencing tokens, and the 'lock ≠ atomicity' lesson. code java implement explain
System 12.1 — URL ShortenerThe perfect first HLD: small data, global scale, one hot read path (redirect) and one rare write path (create). code java implement explainSystem 12.2 — Rate Limiter (HLD)The LLD limiter from Phase 4, now distributed: sticky to one instance won't work, so the counters move to Redis. code java implement explainSystem 12.3 — Notification System (HLD)Fan-out, channel adapters, templates, batching and the provider-failure story — the LLD from Phase 4 at scale. code implement explainSystem 12.4 — File Storage (HLD)Blob storage + metadata DB + edge serving — S3-style, the LLD from Phase 4 at object scale. code implement explainSystem 12.5 — PastebinURL shortener + file storage hybrid: text blobs with read-once/expiry semantics. code implement explainSystem 12.6 — TwitterThe classic read-heavy fan-out problem: write once, read everywhere, and the pull vs push decision for feeds. code java implement explainSystem 12.7 — Instagram (Media Sharing)Twitter + a compressed media pipeline: upload, transform (resize/filter), and serve from CDN via signed URLs. code implement explainSystem 12.8 — News FeedThe read-path emphasis of Twitter: ranking, dedupe, pagination and the per-user inbox model. code implement explainSystem 12.9 — Chat SystemWebSocket gateways, message ordering per conversation, presence, and 'what if the client reconnects'. code java implement explainSystem 12.10 — WhatsApp (Chat at Scale)Chat system with the billion-user add-ons: media messages, end-to-end encryption, delivery receipts. code implement explainSystem 12.11 — YouTube (Video Platform)The media pipeline made enormous: upload, transcode variants, adaptive-bitrate streaming over CDN. code implement explainSystem 12.12 — NetflixYouTube's streaming + the recommendation/open-connect story: regional caching boxes and ML-driven home. code implement explainSystem 12.13 — Dropbox (Sync Engine)The hard part isn't storage — it's reconciliation: chunked sync, delta algorithm, and conflict resolution. code java implement explainSystem 12.14 — Google DriveDropbox sync + collaborative docs + org/quotas layer — mostly the same engine with Google Docs on top. code implement explainSystem 12.15 — Uber (Location-based Matching)The geospatial problem: driver discovery, live positions, matching, pink dot metaphor — and the map is the app. code java implement explainSystem 12.16 — Payment System (HLD)The highest-stakes design: money invariants, idempotency, gateway adapters, reconciliation, webhooks. code java implement explainSystem 12.17 — E-commerceCatalog, cart, checkout, inventory, orders, payments, delivery — the multi-domain orchestration problem. code implement explainSystem 12.18 — Food Delivery (HLD)E-commerce + live geo tracking + delivery assignment — the order lifecycle with real-time tail. code implement explainSystem 12.19 — Ticket Booking (HLD)BookMyShow at scale: multi-tenancy of venues, seat holds, and why inventory sells out 'evenly'. code java implement explainSystem 12.20 — Search EngineThe one HLD that's genuinely different: crawling, indexing, ranking, and serving billions of queries. code java implement explainSystem 12.21 — Distributed LoggingCollecting logs from 10k services into one searchable sink — the ELK/opentelemetry story. code implement explainSystem 12.22 — Metrics / MonitoringPrometheus-style: pull model, label-based time series, alerting, and the golden signals. code implement explainSystem 12.23 — Notification PlatformThe notification system (12.3) elevated to a PLATFORM team product: tenants, templates, delivery SLAs, self-service. code implement explainSystem 12.24 — Distributed Job SchedulerCron at fleet scale: at-least-once scheduling, leases, leader election for periodic jobs, and exactly-one-owner semantics. code implement explainSystem 12.25 — API Gateway (HLD)The gateway as a product: routing, auth, quotas, rate limiting, observability — scaled and made boring. code implement explainSystem 12.26 — Feature Flag PlatformFlags as a product: evaluation service with edge caching, targeting rules, audit, and kill switches. code implement explainSystem 12.27 — Workflow EngineThe saga state machine as a product: durable steps, retries, human tasks, and the event-driven revival. code implement explainSystem 12.28 — Test Execution PlatformCI test runners as a service: job scheduling, resource pools, parallelism, artifact collection. code implement explainSystem 12.29 — CI/CD PlatformThe delivery pipeline as a product: stages, artifacts, approvals, blue/green and canary deployment. code implement explainSystem 12.30 — Multi-tenant SaaS PlatformOne codebase, many customers: isolation, tenancy models, quotas, billing, and the scaling per tenant. code implement explainSystem 12.31 — Typeahead / Search AutocompleteSuggest the top completions for every keystroke in under 100 ms: a read-heavy, latency-critical system built on precomputed prefix → top-K lists, fed by an offline aggregation of search logs. code implement explainSystem 12.32 — Web CrawlerFetch billions of pages politely and efficiently: a URL frontier with per-host politeness, distributed fetchers, deduplication of URLs and content, and robust parsing, all without hammering any single website. code implement explainSystem 12.33 — Distributed Key-Value Store (Dynamo-style)Design a highly available, horizontally scalable `get/put` store: consistent hashing with virtual nodes, replication with tunable quorums, versioning and conflict resolution, hinted handoff, gossip membership, and Merkle-tree repair. code implement explainSystem 12.34 — Proximity Service (Nearby Places / Yelp)Find businesses near a location, with filters and ranking. Places change rarely and reads dominate, so a geospatial index (geohash/quadtree) cached per cell serves millions of 'nearby' queries cheaply. code implement explainSystem 12.35 — Collaborative Document Editor (Google Docs)Many people typing in the same document at once, seeing each other's changes in real time, even offline. The heart is conflict-free merging of concurrent edits with Operational Transformation or CRDTs over WebSockets. code implement explainSystem 12.36 — Real-Time LeaderboardRank millions of players by score in real time and show anyone's rank and neighbours instantly. Redis sorted sets do the heavy lifting; the design questions are durability, sharding very large boards, and time-windowed boards. code implement explainSystem 12.37 — Ad Click Aggregation & Top-K Heavy HittersCount billions of ad clicks per day accurately enough to bill advertisers and show live dashboards: stream aggregation with windows and watermarks, exactly-once-ish processing with reconciliation, and top-K ads per minute. code implement explainSystem 12.38 — Hotel Reservation SystemBook rooms without double-booking under concurrency and overbooking policies: inventory per room type per date, strong consistency on the booking path, idempotent reservation requests, and caching for search. code implement explainSystem 12.39 — Distributed Message Queue (design Kafka)Design the log-based queue itself: partitioned append-only logs on disk, leader/follower replication with in-sync replicas, consumer groups with offsets, retention, and the trade-offs behind high throughput. code implement explain
13.1CAP TheoremDuring a network partition you choose between consistency and availability — and the answer is per-component, per-moment. code implement explain13.2PACELCCAP's rarely-quoted second half: even without a partition, you choose between latency and consistency (Else Latency vs Consistency). implement explain13.3Strong ConsistencyLinearizable behavior: a read after a write always sees the write — the default you assume with one database. implement explain13.4Eventual ConsistencyReplicas converge eventually — the default of any replicated system that doesn't synchronize every read. java implement explain13.5LinearizabilityThe precise form of strong consistency — operations take effect at a single point in real time. implement explain13.6QuorumW + R > N: read the majority so at least one overlapping node has the latest write. code implement explain13.7Leader ElectionExactly one node acts as leader at any time, others follow — via leases, fencing, and a consensus-safe tiebreaker. code java implement explain13.8Distributed Consensus (Raft, Paxos)The problem behind 'everyone agrees on the same order': Raft and Paxos, and why you almost always use etcd/ZK/Raft behind a library. implement explain13.9Distributed Locks (deep)The lease + fencing story done properly — and when a lock is the wrong tool (idempotency often beats locks). implement explain13.1013.11 — Distributed Transactions & 2PCTwo-phase commit's prepare/commit protocol — and why production prefers saga/outbox for everything except narrow windows. implement explain13.12Event SourcingStore the history of changes as an append-only event log — the state is derived, never stored as a mutable row. code java implement explain13.13CQRSSeparate the read model from the write model — different schema, different store, different scaling. code java implement explain13.14Data Consistency PatternsThe pattern library you choose from per flow: outbox, saga, event sourcing, CQRS, TTL caches, read-your-writes, idempotency. implement explain
Topic 13B.1 — Storage Engines: B-Trees, LSM Trees & the WALUnder every database is a storage engine that decides how bytes hit the disk. B-trees update data in place and excel at reads; LSM trees append and merge later and excel at writes. Knowing which one you're on explains most performance behaviour. code implement explainTopic 13B.2 — Unique ID Generation at ScaleAuto-increment IDs need one central counter; random UUIDs scatter indexes. Distributed systems use time-ordered IDs (Snowflake, UUIDv7, ULID) that are unique without coordination and sort by creation time. code java implement explainTopic 13B.3 — Bloom Filters, HyperLogLog & Count-Min SketchWhen exact answers are too big or too slow, probabilistic structures give almost-right answers in tiny memory: 'definitely not present' (Bloom filter), 'about 48 million unique visitors' (HyperLogLog), 'roughly how often' (Count-Min Sketch). code java implement explainTopic 13B.4 — Geospatial Indexing: Geohash, Quadtrees & H3'Find drivers within 2 km' can't scan every driver. Geospatial indexes turn 2-D locations into cells or keys you can look up quickly: geohash strings, quadtrees that split busy areas, and hexagonal grids like H3. code implement explainTopic 13B.5 — Time, Clocks & Ordering: Lamport, Vector Clocks, HLCMachines' clocks disagree, so 'which happened first?' can't be answered with timestamps alone. Logical clocks capture cause and effect; vector clocks detect concurrent conflicting writes; hybrid clocks combine both with real time. code implement explainTopic 13B.6 — Gossip, Failure Detection & Merkle TreesLarge clusters can't have every node ping every other node. Gossip spreads membership and state epidemically, phi-accrual detectors decide who's dead, and Merkle trees let replicas find differences by comparing a few hashes. code implement explainTopic 13B.7 — Batch vs Stream Processing, OLTP vs OLAPOperational databases serve the app (OLTP); analytics needs different storage (OLAP). Batch jobs process large bounded datasets periodically; stream processing handles unbounded events continuously. Most companies run both, connected by change data capture. code implement explainTopic 13B.8 — Backpressure, Load Shedding & Admission ControlWhen demand exceeds capacity, a system must slow producers down, reject some work gracefully, or collapse. Bounded queues, backpressure, load shedding by priority, and adaptive concurrency limits keep it standing. code java implement explain
14.1ReliabilityFailover, redundancy, replication and health checks — the mechanisms that make downtime an exception, not a feature. code implement explain14.2Disaster RecoveryRPO, RTO, backup and restore at the REGION level — the plan for when the whole datacenter dies. code java implement explain14.3ObservabilityLogs, metrics, traces — three signals, one question: 'what is happening and why?' (Prometheus, Grafana, OTel, ELK). code java implement explain14.4SecurityAuthentication, authorization, OAuth2, JWT, mTLS, secrets, encryption — the seven walls of a real system. code java implement explain14.5Multi-tenancyShared infrastructure, isolated tenants — the SaaS operator's architecture, with a real isolation decision. implement explain14.6Rate Limiting (Production)The production-shaped limiter: global policies, edge enforcement, quotas per tenant, and the fail-open story. implement explain14.7Data PrivacyGDPR-grade concerns in designs: retention, deletion, PII classification, consent, and the 'right to be forgotten'. implement explain14.8Cost OptimizationThe question every senior interviewer actually asks: what does this architecture cost, and what can we remove? implement explain
Template — The 13-Step HLD AnswerThe HLD interview skeleton: 13 steps that work for Twitter, Uber, payment systems, or a CI/CD platform. Run them in order, out loud. code java implement explainTemplate — The 13-Part LLD AnswerThe LLD analogue: requirements → actors → use cases → entities → responsibilities → relationships → interfaces → SOLID → patterns → extensibility → concurrency → code → tests. code implement explainThe Learning Loop — How to Study Every TopicThe syllabus's core loop: Learn → Close the tutorial → Explain without notes → Implement → Break it → Fix it → Explain trade-offs. Never stop at definitions. implement explainThe First 10 Study SessionsThe syllabus's starting order — don't read the whole roadmap daily; run this schedule, sequentially, before anything advanced. implement explainThe Completion Checklist — You're 'Done' When…The syllabus's graduation test: the things you must be able to do with the tutorial closed. This is the actual objective of the whole course. implement explain