Cruxly › System design interview preparation

System design interview preparation

System design interviews reward a repeatable method and sound judgement about trade-offs, not memorised architectures. The path runs eight weeks: first the method, then fundamentals of data systems (storage, indexing, replication, partitioning, consistency, databases), scalability and high availability (caching, load balancing, rate limiting), reliability and observability, microservices and messaging, the principles that tie the trade-offs together, and finally full design exercises that use all of it. Each lesson links to an interactive version with animated walkthroughs.

Running the Design Interview

The four moves that turn a vague prompt into a defensible system, in order.

• Scoping the Problemnarrow the prompt before you build anything
• Estimating the Loadget to one number that constrains everything else
• The First Diagramsmallest system that meets the numbers
• Designing the APIthe contract you write before the boxes: nouns, cursors, idempotency keys, compatible change and errors a client can act on
• Deep Dives and Trade-offsbreak your own design before the interviewer does

Foundations of Data Systems

Qualities you can measure, how time and failure behave across machines, batch and stream processing, then the indexing, replication and partitioning choices every design rests on.

• Reliable, Scalable, Maintainable: Measuring a Systemthree adjectives that mean nothing until each one has a number, a distribution and an owner
• Clocks, Ordering and Partial Failureyou cannot tell crashed from slow, and you cannot trust the clock to say which write came last
• Choosing a Datastoreaccess pattern first, product second
• How Indexes Actually Workthe data structure decides what your database is fast at
• Replication and Consistencycopies disagree; decide who notices
• Partitioning and Shardingthe shard key is the design
• Transaction Isolation Levelswhat can go wrong between two transactions, named precisely
• CAP and PACELC, Preciselythe theorem behind the advice you were already given
• Distributed Consensusgetting several machines to agree on one thing, once, even when some fail
• Batch and Stream Processingthe same computation over data that has an end, or data that never does, and the price of each

Databases: Choosing One

How to pick a datastore, defend it, and say what it costs, from ACID to case studies.

• How to choose a databasestart from the workload, default to relational, leave for a measured reason
• ACID, preciselyfour promises, four owners, and where each one leaks
• Isolation levels, in depthsnapshots, write skew and serializability: what your engine really guarantees
• Data models: what each family is built for, and where it failsevery family is a data structure plus an access path; learn which queries it makes cheap
• Storage engines: B-trees, LSM-trees, row vs columnthe engine under the database decides which workloads it can survive
• NoSQL modelling in practice: DynamoDB, Cassandra, MongoDBlist the queries first, give each one a key, and know the limit and the cost of every copy
• Distributed SQL: Spanner, CockroachDB, Aurora and friendsSQL and ACID across machines and regions: what you get, and the latency, clock and operations bill
• Scaling Postgres and MySQL before you leave thema ladder of cheaper, reversible steps, climbed in order, each with a signal
• Operating a database: backups, migrations, multi-region, costthe part of the choice candidates forget
• Choosing the database: seven worked case studiessame method, seven systems, seven different answers
• Consistency models, for the person choosingname the guarantee a user needs, pick the weakest model that gives it, and say what it costs

Databases by Name: Internals and Terms

The terms, defaults and failure modes each database is known for, taught the way staff engineers argue about them, with sourced postmortems from companies that run them.

• PostgreSQL internals: MVCC cost, VACUUM, wraparound and WALevery update leaves a corpse, and the vacuum that cleans them is the thing that pages you
• MySQL and InnoDB: locks, buffer pool, replication and Vitessthe clustered-index engine behind Slack, Shopify and GitHub, and the knobs that decide whether it holds
• Redis in depth: cluster slots, eviction, persistence and the lock debatean in-memory structure server with a durability story that is mostly about which seconds you can lose
• Cassandra and ScyllaDB: the ring, repair, compaction and Discord's migrationa masterless ring that scales writes until compaction, repair and one hot partition remind you what it costs
• DynamoDB under the hood: partitions, adaptive capacity, quotas and the 2015 outagea managed key-value store whose limits are per partition, and whose worst day came from a metadata service
• MongoDB internals: oplog, WiredTiger, shard keys, the balancer and Stripe's DocDBdocuments are easy; the oplog window, the cache and the shard key are what you operate
• Kafka as a log store: ISR, acks, compaction, transactions and LinkedIn scalea replicated commit log whose guarantees are three config lines: acks, min.insync.replicas and unclean leader election
• Elasticsearch and OpenSearch: shards, refresh, translog and shard sizinga search index that is never quite real time, and a shard count you cannot easily change
• ClickHouse and columnar OLAP: MergeTree, parts, insert batching and Cloudflarefast scans because the data is sorted and sparse-indexed, fragile when you insert one row at a time
• How top companies run their databases: postmortems, migrations and what to copyten sourced stories, read as an engineer: version, number, failure, what changed

Scaling Building Blocks

Components that appear in almost every design, and what each one actually costs.

• Scaling Up, Scaling Out and Splittingbuy time with a bigger box, buy capacity with more boxes, and split along the line that actually carries the load
• Load Balancing, CDNs, and the API Gatewayeverything the request meets before it reaches your code
• Cachingbuys latency, costs freshness
• Cache Eviction and Topologywhich key to evict, and which machine owns it
• Distributed Cache Clustersharding a cache so adding one node doesn't invalidate almost everything
• Content Delivery Networkcaching close to the reader, invalidating across nodes you don't control individually
• Rate Limitingprotect the system, and the limit must be shared
• Long-Polling, WebSockets, and Server-Sent Eventsthe server has news — how does the client find out

Reliability and Observability

SLAs and availability maths, overload and cascading failure, disaster recovery, and the monitoring, logging and tracing that show it is working.

• SLAs, Availability Math and Error Budgets as Design Inputsa target is a design input: it decides how many dependencies you may call, how many copies you run, and when releases stop
• Designing for Observabilityyou will be debugging this at 3am with only what you built in
• Metrics Pipelinewrite volume so high the storage shape is the design
• Distributed Tracing Systemreconstructing one request's path across fifty services from logs that don't know they're related
• Overload, Load Shedding and Cascading Failurea system that does everything it is asked at the top of the curve ends up doing nothing
• Disaster Recovery: Backup, Pilot Light, Warm Standby, Active-Activedecide what counts as a disaster, pay only for the recovery that its RPO and RTO justify, and prove it works before the day you need it

Microservices and Events

Where to cut a system into services, how services talk and fail together, and event-driven designs with Kafka and RabbitMQ.

• Decomposing a System into Servicesthe hard part of microservices is not the network, it is deciding where the lines go and who owns the data behind each one
• Service-to-Service Communication: Discovery, Mesh, Identity and Compatibilityevery call between services is a promise that two teams can break independently, so choose the style, find the peer, prove who you are, and…
• API Gatewayone front door for services that disagree about almost everything
• Queues and Async Workdecouple the spike from the work
• Event-Driven Architecture: Choreography, Orchestration and Sagasevents decouple who knows about whom; they do not decouple who must be correct, and that is where the saga, the outbox and the inbox come in

Advanced Trade-offs

Monolith or microservices, CQRS and event sourcing, and when each is overkill: the decisions seniors are asked to defend.

• Monolith, Modular Monolith or Microservices: a Trade-off Analysisthe architecture question as a costed decision: what distribution charges, what one deployable charges, and the trigger that flips the…
• CQRS and Event Sourcingtwo patterns that are often sold together and should be bought separately, each with a price that most systems should not pay
• Workflow Orchestration Engineresuming from exactly where it crashed, days later, without redoing what already happened

Principles of Distributed Design

Six named principles that turn 'this feels right' into an argument you can defend — each motivated by a failure, each with its cost stated.

• State Gravitystate is the expensive thing; keep the set of things that have it small
• Asymmetry Firstfind the axis where the distribution is wildly uneven, and design to that
• Failure Is a Mode, Not an Exceptionfor every dependency, the question is what the system does when it's down — not whether it can be
• Truth Has One Homefor every fact, name the single component that owns it — everything else holds a copy
• Make the Expensive Path Rareif you cannot make an operation fast, make it uncommon
• Boundaries Are Where Guarantees Dieat every hop, name the guarantee you just lost

Design Exercises

Problems worked end to end, each chosen because it forces one hard decision.

• Short Links at Scaleid generation without coordination; 10000:1 reads
• Activity Feedfan-out on write vs read; the celebrity problem
• Real-time Messagingconnection state, ordering, offline delivery
• Seat Bookinga correctness constraint that forbids eventual consistency
• Notification System (HLD)one event, five channels, one user who must never be paged twice
• Search Autocomplete (HLD)the index has to be wrong on purpose, because right-but-slow loses every time
• Payment Ledgermoney cannot be lost, double-spent, or invented
• Video Streamingthe bytes are too big to move at request time
• Ride Matchingan index over a set that never stops moving
• Order Matching Enginedeterminism first, and the fastest correct thing is one thread
• Web Crawlerthe frontier is the hard data structure, not the fetching
• Distributed Job Schedulerexactly-once execution when the executor can die mid-job
• File Storage and Syncconverging on the same bytes without re-sending what hasn't changed
• Distributed ID Generatorunique, roughly sortable IDs from machines that can't coordinate
• Ad Click Aggregationcounting billions of events exactly once when the network lies
• Distributed Lock Servicea lock that can outlive the process holding it
• Collaborative Document Editingtwo people typing in the same paragraph, and both edits must survive
• Proximity Searchindexing a plane instead of a key space
• Multiplayer Game State Synchiding 100ms of network latency from a player who expects their keypress to happen now
• OTP / Two-Factor Authenticationa six-digit code is a tiny search space — the design has to survive someone guessing
• News Feed Rankingscoring happens offline in batch, but the feed must feel instant and current
• Feature Flag Platformchanging behavior for one user in production, right now, with no deploy
• Bulk Email Deliveryreputation, not throughput, is the actual constraint
• Social Graph Storagea relationship, not a record, is the unit of data
• Webhook Delivery Systemyou are the client now, and the server you're calling can be down for as long as it wants
• Project & Issue Tracking Systema workflow isn't a status field, it's a graph the tenant defines and you enforce
• LLM-Backed Query Systemthe model is the one component in this system whose behavior you cannot fully specify
• Prepaid Recharge & Wallet Systemthe money moves exactly once, even when your own server retries the request that moves it
• Distributed Rate Limiter Servicea counter that hundreds of gateways share, on a path that cannot afford to wait for it
• Distributed Message Queuea durable log, a partition count you cannot easily change, and delivery guarantees that stop at the edge of the broker