Compare · system design decisions
The diagram gets you through the first ten minutes of a system design interview. The rest is why you chose Redis over the database, and what happens when Redis says OK and then forgets. Each family page takes one problem from the same online shop and puts every product against it: what it does, what breaks, what it promises, and where that promise stops. Every claim is checked against the vendor's own documentation.
The other 6 live families need Premium. 13 more families go live before the end of this month, one at a time, as each passes review.
Come with one question
"Why Redis and not the database?" "Which copy still has the order when Virginia dies a second after it said committed?" Every section on a family page answers one question like that. Open the section you need and leave. You never have to read a whole family.
The shape is the answer, the product is the example
Anyone can draw a cache box and a queue box. A staff engineer says which shape is inside the box, what it gives up, and where its promise stops: one key, one partition, one region. That one sentence separates two candidates who drew the same diagram.
Know what breaks before they ask
Every family shows the failure the interviewer is about to raise: the primary that said OK and died, the retry that puts the old price back, the shard that answered late with HTTP 200. Walk in having seen it, or meet it for the first time in the room.
Product copies or shared session state: which fast store fits the data model, freshness and failure requirements?
Caches and fast key-value stores. Serve frequently read data from a fast store: a rebuildable product copy, or the authoritative session record. Compare the data model, freshness and failure behavior before choosing where the data lives.
5 problems, 2 scenarios, 17 things compared
Two billion orders, and the app almost always asks for one customer's records. DynamoDB, Cassandra, ScyllaDB or Bigtable? And what do I give up: joins, transactions, or a fresh read?
Distributed key-value and wide-column databases. Keep billions of records spread over many machines, and find any one of them by its key in a few milliseconds. Two you can run yourself and two a cloud runs for you, all four splitting the data by key.
5 problems, 2 scenarios, 18 things compared
My checkout must not wait for the email to be sent. Which queue or stream, and does it keep the history?
Work queues and event streams. Move slow work out of the request through a reliable handoff. Choose between shared tasks and retained events that independent services can read or replay.
5 problems, 2 scenarios, 17 things compared
Emma types 'ketle' in the search box. Which search engine, or can the database do it?
Search. Find and rank products from words, typos and filters. Compare where the index lives, how soon a change shows, and the work of keeping a search copy in step with the database.
5 problems, 2 scenarios, 18 things compared
Orders, customers and stock in tables that must never half-save. Postgres or MySQL? Run it myself, or let RDS, Aurora or AlloyDB run it? And what happens when one machine isn't enough?
Relational databases. Keep the shop's orders, customers and stock in tables where three changes save together or not at all. Two engines, PostgreSQL and MySQL, and three ways to run them: on your own machines, managed on its own disks, or managed over shared storage.
5 problems, 3 scenarios, 21 things compared
One Postgres primary is not enough any more. Spanner, CockroachDB, YugabyteDB, TiDB or Aurora DSQL? Or do I split the database I have into pieces?
Distributed SQL. Keep tables, SQL and transactions when one machine can no longer take every write, or when both coasts must write at once. Three you run yourself or rent, and two that exist only as a cloud service.
5 problems, 2 scenarios, 17 things compared
Each order is a tree: customer, address, products, payment. MongoDB? Firestore? Or JSON in the Postgres I have?
Document databases. Store the order as one record, the tree of customer, address, lines and payment, and change it as one unit. Two you run yourself or rent, two that exist only as a cloud service, and the column in the Postgres you already have.
5 problems, 2 scenarios, 17 things compared
The shop has 2 billion historical orders. Finance wants revenue by product for the last year, counting each order line once. Where can that report run without slowing checkout?
Warehouses and lakehouses. Answer questions over every order the shop has ever taken, such as revenue by product for the year. Do this without slowing the database that takes new orders.
Rebuilt to the new format. Live before the end of this month, after review.
Every product page asks 'bought 12 times in the last hour', 2,000 times a second. Which event store fits the freshness, count correctness and correction requirements?
Real-time analytics (OLAP). Serve selective event queries and live dashboards. Compare freshness, exact counts, indexes, updates and SQL before choosing the store.
Rebuilt to the new format. Live before the end of this month, after review.
300 servers report checkout latency every 15 seconds. The on-call screen wants the last 5 minutes, and finance wants 13 months. Which store?
Time series. Store timestamped observations and event history. Compare collection, series growth, window statistics, corrections and retention with an explicit freshness contract.
Rebuilt to the new format. Live before the end of this month, after review.
'Customers who bought the kettle also bought' over 200 million orders: which graph model and store can meet the product page's latency and correctness requirements?
Graph databases. Follow explicit relationships to answer recommendations and bounded fraud questions. Compare access paths, result correctness, transaction boundaries and graph placement before choosing a store.
Rebuilt to the new format. Live before the end of this month, after review.
'Products like the kettle' over 2 million products, in stock and under $50, 500 times a second. Which store holds the embeddings, the numbers a model turns each product into?
Vector retrieval. Find similar products, documents or images using embeddings. Compare retrieval quality, filters, freshness and operating cost.
Rebuilt to the new format. Live before the end of this month, after review.
5 million product images and an invoice PDF per order. Where do the files live, and how does Emma's browser get one?
Object and file storage. Store product images, invoices and catalogue uploads, and choose how applications and browsers write and read them.
Rebuilt to the new format. Live before the end of this month, after review.
Count orders in any five-minute span and keep product stock current. What happens when an event arrives late or a worker fails?
Stream processing. Compute running counts, match events and evaluate rules as records arrive. The choice depends on time, saved state and what happens when processing or an output write fails.
Rebuilt to the new format. Live before the end of this month, after review.
Order 881 was charged before the server restarted. How does fulfilment continue, and what if the payment reply was lost?
Durable workflows. Keep the progress of a multi-step operation so another attempt can continue after a crash. Separate a recorded result from a payment whose reply was lost, and track recovery when a later step fails.
Rebuilt to the new format. Live before the end of this month, after review.
A paused worker wakes after another took over. Which system prevents its old write, and what happens if the action is a carrier booking?
Coordination. Choose which worker may update a shared order or stock import. When a worker pauses or loses its connection, the receiving database must still reject work from a replaced owner.
Rebuilt to the new format. Live before the end of this month, after review.
Emma's tracking page must show 'shipped' within a second, on 20,000 open tabs. Which one pushes it, and what happens when her phone drops?
Real-time delivery. Push a change to the browsers and phones that are looking at it right now. Emma's tracking page shows 'shipped' the second it happens.
Rebuilt to the new format. Live before the end of this month, after review.
Three checkout instances, one hangs, a canary to ship, a script hammering the API. Which one stands in front and decides where each request goes?
Traffic routing and delivery. Stand in front of the shop's servers. Send Emma's request for the kettle page to the web servers and her checkout call to the checkout service.
Rebuilt to the new format. Live before the end of this month, after review.
Two teams keep blocking each other's releases. Split the shop into services, or not?
Architecture styles: monolith, modular monolith, microservices and serverless functions. Decide where the boundaries in the shop's code go, and what kind of boundary each one is. A module inside one process, a service on the network, or a function on a managed runtime.
Rebuilt to the new format. Live before the end of this month, after review.
Two servers must create order ids at the same time without talking to each other. Which id?
Unique IDs: sequences, UUIDv4, UUIDv7, ULID, Snowflake-style and KSUID. Give order 881 an id that two servers can create at the same moment without talking to each other. The id must never repeat.
Rebuilt to the new format. Live before the end of this month, after review.
A cache keeps a copy of the record in memory, where a read takes under a millisecond. The database stays the owner of the truth. The copy may be a little old, and the application decides how old is acceptable. Some products here can also be the only copy, such as a login session. Then database rules apply.
Why this family exists, before any product
The product database answers every kettle page read from disk and its own memory. At 50,000 reads a second it is the slowest and busiest part of the shop, and every other query waits behind those reads.
The shapes in the family
A copy inside the process · A shared in-memory server · An in-memory data grid · A record store with an index in memory and records on SSD
Questions to ask first
Questions about data, freshness, failure and load whose answers narrow the candidates. Less urgent questions are marked as able to wait.
Five problems, drawn with no product in them
The server said 'saved'. Is Emma's session safe?
Then how each product handles that same problem
5 product-specific mechanisms for the same problem.
How each one is built
One drawing of the machine per product: what a read and a write do inside it, what limits it, and what is different. Redis: A single command execution thread makes operations such as a Lua script or an EXEC command sequence run without interleaving other clients’ commands. Atomic execution does not mean rollback or guaranteed durability.
When it fails
One of the two cache servers restarts with empty memory. The main server dies and a replica takes over. The 'price changed' delete or message never arrives. The cache is up but does not answer in time. The network splits the cluster in two.
More things to compare
Compare data models and update operations alongside correctness, scaling and operational limits. Each product has a short answer and relevant qualifications.
Two scenarios from the shop, and what changes them
How can we serve 50,000 product views per second without exceeding 5,000 database reads per second, even if a cache server fails?
Decide: the matrix, then the questions in order
Guarantees with their boundaries, a matrix built from the checked claims, and a decision flow that starts with: Is the cache the only copy of the data, like sessions or carts?
How to answer it in an interview
Worked answers connect the requirements, decision, downside and changed requirement. Sources follow for checking the details.
Plain answers keeps the explanation and decision-changing warnings visible. Full details adds version scopes, mechanisms and source links. Inferred claims are labelled.
Each family is three symptoms. Find yours, then open that family.
Caches
Distributed key-value
Work queues
Search
Relational databases
Distributed SQL
Document databases
WarehousesComing soon
Real-time analytics (OLAP)Coming soon
Time seriesComing soon
Graph databasesComing soon
Vector retrievalComing soon
ObjectComing soon
Stream processingComing soon
Durable workflowsComing soon
CoordinationComing soon
Real-time deliveryComing soon
Traffic routingComing soon
Architecture styles: monolith, modular monolith, microservicesComing soon
Unique IDs: sequences, UUIDv4, UUIDv7, ULID, Snowflake-styleComing soon