Talking Through Trade-offs

A five-part sentence for every design choice, worked on SQL vs NoSQL, caching, sync vs async, consistency and push vs pull, with strong and weak scripts.

18 minLesson 1 of 5
On this page
  1. The five-part sentence
  2. Five classic choices
  3. In the interview
  4. Common mistakes
  5. What to practise next

Two candidates draw the same design for an online shop. The interviewer asks each one why the orders table lives in a relational database. The first says "SQL is more reliable, and NoSQL doesn't scale as well." The second says "Placing an order writes the order and decrements stock together, so I want a transaction. At 200 orders a second one primary is plenty. If we needed tens of thousands of writes a second, I'd look at a partitioned store and give up the cross-row transaction."

Same choice, but only the second answer tells the interviewer anything. Here is a sentence shape that produces it on demand, worked on five choices that come up in almost every interview.

The five-part sentence

A trade-off answer has five parts. Say them in this order and you rarely leave one out.

The pattern
1. Option     "I'll use X."
2. Buys       "It gives us ..."                      (the benefit, concrete)
3. Costs      "The price is ..."                     (what gets worse)
4. Fits       "That's right here because ..."        (tie it to a requirement or a number)
5. Changes    "If ... changed, I'd switch to Y."     (the condition that flips it)

Parts 3 and 5 separate candidates. Naming the cost of your own choice shows you see the whole picture. Naming what would change your mind shows the choice came from the requirements, not habit, and hands the interviewer a follow-up on ground you prepared.

Part 4 needs a fact from earlier, such as a read/write ratio or a rule like "no double bookings". Skip requirements and estimates and you have nothing to tie it to.

Five classic choices

SQL or NoSQL

Frame it by access pattern: what you read and write together, and whether you need transactions across rows. Choosing a database covers the categories.

Defending the databaseWeak answer
Interviewer

Why a document store for orders?

You

NoSQL scales horizontally and it's more flexible. SQL databases get slow at scale.

Defending the databaseStrong answer
Interviewer

Why a relational database for orders?

You

An order writes the order row and decrements stock, and both must happen or neither. A relational database gives me that transaction. The cost is that one primary takes all writes. At 200 orders a second, against a few thousand writes a second per primary, that's fine. If we grew to tens of thousands a second and every read was by order id, I'd move to a key-value store partitioned by order id and handle stock with a separate reservation step.

Cache or no cache

Sometimes the strongest move is to decline one. An admin tool doing 5 reads a second does not need a cache: it would add a component and a staleness problem for no gain.

Strong: "Profile reads are 100 times the writes and a small share of profiles get most views, so I'll put a cache in front, with a 5-minute TTL and a delete on write. The cost is a profile can look stale to other users for a moment. If writes became as common as reads, the hit rate would drop and I'd remove it." The caching lesson has the details.

Synchronous or asynchronous

Ask: does the user need this step's result before we answer? A card charge, yes. The receipt email, no. Anything the user does not wait for can go through a queue, so its failures stop being the user's failures. Step through a checkout while the email provider is down.

Checkout with the email step made asynchronousUse the arrows or ← → keys
  1. Checkout with the email step made asynchronous, step 1Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorEmail queueOrders DBEmail workerEmail providerPOST /orderschargeinsert ordersend
    shopper waiting
    yes

    1A shopper places an order. Checkout answers only after the steps the shopper must know about.

  2. Checkout with the email step made asynchronous, step 2Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorEmail queueOrders DB9071 pendingEmail workerEmail providerPOST /orderschargeinsert ordersend
    shopper waiting
    yes

    2It writes order 9071 as pending first, so no card is ever charged without a record of why.

  3. Checkout with the email step made asynchronous, step 3Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorapprovedEmail queueOrders DBEmail workerEmail providerPOST /orderschargeinsert ordersend
    shopper waiting
    yes

    3It charges the card synchronously, with the order id as the idempotency key so a retry cannot charge twice. The shopper must know whether this worked, so waiting is right.

  4. Checkout with the email step made asynchronous, step 4Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorEmail queueOrders DB9071 paidEmail workerEmail providerPOST /orderschargeinsert ordersend
    shopper waiting
    yes
    queued emails
    1

    4It marks the order paid and drops a "send receipt for 9071" message on the queue. It does not wait for the email.

  5. Checkout with the email step made asynchronous, step 5Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorEmail queueOrders DBEmail workerEmail providerPOST /orderschargeinsert ordersend
    shopper waiting
    no
    queued emails
    1

    5The shopper sees "Order placed". Enqueueing took about a millisecond; sending the email is not on the shopper's clock at all.

  6. Checkout with the email step made asynchronous, step 6Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorEmail queueOrders DBEmail workerEmail providerdownPOST /orderschargeinsert ordersend
    shopper waiting
    no
    queued emails
    1

    6The worker takes the message and calls the email provider, which is down.

  7. Checkout with the email step made asynchronous, step 7Shopper to Checkout service (POST /orders); Checkout service to Card processor (charge); Checkout service to Orders DB (insert order); Checkout service to Email queue, asynchronous; Email queue to Email worker, asynchronous; Email worker to Email provider (send).ShopperCheckout serviceCard processorEmail queueretry in 60 sOrders DBEmail workerEmail providerdownPOST /orderschargeinsert ordersend
    shopper waiting
    no
    queued emails
    1

    7The message goes back on the queue to retry in a minute. Orders keep succeeding. Called directly, this outage would have failed every checkout.

1 / 7

Say the cost: the email can arrive minutes late, and a retry can send it twice unless the worker is idempotent. If checkout crashes between marking the order paid and enqueueing, the receipt is never sent; an interviewer may push here. Write the email job into the orders database in the same transaction (an outbox) and let a relay move it to the queue. What would change the choice: an email carrying a login code the user is staring at must go out right away.

Strong or eventual consistency

Be precise; interviewers notice loose words. Strong (linearizable) means once a write is acknowledged, every later read sees it. Eventual means replicas converge if writes stop, with no promised bound on staleness before then. A replica that "lags about a second" is eventual consistency with a typical lag, not a guarantee. CAP and consistency covers the models, and why a quorum is not strong consistency.

Strong: "Seat reservations need strong consistency because two people must never get seat 14C, so a reservation is a conditional write on the primary: take the seat only if it is still free. The seat map people browse can be eventually consistent, a few seconds stale, since the reservation itself is checked. If we went multi-region, I'd have one region own each event's seats." It splits one feature into two operations with different needs.

Push or pull

For a feed, push writes each new post into every follower's feed (fan-out on write). Pull builds the feed from the accounts you follow when you open it (fan-out on read).

Feed delivery: where to pay the fan-out cost
OptionGood atBad atPick it when
Push (fan-out on write)Reads are one lookup of a ready feed: fast and cheap.A post by someone with 10 million followers costs 10 million writes.Most users have a few hundred followers and reads far outnumber posts.
Pull (fan-out on read)A post is one write, whoever posts it.Each feed load reads from every account you follow and merges, so reads are slow and costly.Few readers, or follow counts are small and feeds are rarely opened.
Hybrid Usual defaultPush for ordinary accounts, pull for the few huge ones at read time.Two code paths, and a threshold to tune.Follower counts are very uneven, which is the usual case in an interview.

The news feed case study works the arithmetic through.

In the interview

Use the full sentence for the three or four decisions that shape the design. For small ones a clause is enough: "round robin, since the servers are identical".

  • "The price of this is..." Say it before they ask.
  • "This fits because we said reads are 100 times writes."
  • "If that number were ten times higher, I'd switch to..."
  • "Both work at 200 a second; I'll pick the one the team already runs." An honest tie is a fine answer.

Follow-ups you should expect:

  • "What if you're wrong about that number?" Say which part of the design breaks first and how you would notice: "if writes are ten times higher, the single primary saturates; I'd watch write latency and plan partitioning before it does."
  • "Why not the other option?" Give its strength first, then the cost that rules it out here.
  • "Can you have both?" Sometimes, per operation, as with the seat map and the seat reservation. Say what each operation gets.

Common mistakes

Quick check

Which part of the five-part sentence is missing? "I'll queue the thumbnail jobs so uploads return fast. That fits, since users don't need the thumbnail right away. If users had to see the thumbnail before posting, I'd do it inline."

Profiles are read 100 times for every write. A candidate says "profile reads are strongly consistent because they go to a replica that lags under a second." What is wrong?

A feed product: most users have about 300 followers, a few have 5 million. Each post by a 5-million account under pure push costs how many feed writes, and what do you choose?

What to practise next

See the habits that lose interviews, many of them failed trade-offs, in System Design Mistakes. Then practise the sentence on a full case such as Design Ticket Booking.