The 20-minute warm-up

1. 1

   Clarify before you build

   Restate the problem and pin the one constraint that dominates — scale, consistency, latency, or cost. The rest of your answer hangs off it.

2. 2

   Name the axis, then the tool

   Say what the decision turns on before you say Postgres or Kafka. Interviewers hire the reasoning, not the noun.

3. 3

   Default, then exception

   Give your default in one sentence, then the specific condition that would change it. Certainty plus a hinge beats a survey of options.

4. 4

   Failure first

   Name how it breaks — the hot partition, the thundering herd, the split brain — and what you’d measure to catch it. Seniors design for the bad day.

5. 5

   “It depends” needs an on-what

   The phrase is only strong when the very next sentence names the variable it depends on. Otherwise it reads as a dodge.

The common “X vs Y” calls, each in one line. If you can say the default and the switch condition without thinking, you’ve won the decision.

• SQL vs NoSQL

  Default to relational (Postgres). Reach for NoSQL only when a specific access pattern or scale requirement makes relational a poor fit.

• REST vs gRPC vs GraphQL

  REST for public, cacheable, resource APIs; gRPC for fast internal service-to-service calls; GraphQL when varied clients need to shape their own queries.

• Kafka vs RabbitMQ vs SQS

  Kafka is a replayable log for event streaming; RabbitMQ is a flexible broker for task queues; SQS is a zero-ops managed queue on AWS.

• Monolith vs Microservices

  Start with a modular monolith. Move to microservices only for a concrete driver — independent scaling, team autonomy, or fault isolation — and only with the ops maturity to run a distributed system.

• Strong vs Eventual Consistency

  Strong consistency when correctness needs every reader to see the latest write (money, inventory, uniqueness); eventual when availability and scale matter more and brief staleness is tolerable (feeds, counts, caches).

• Synchronous vs Asynchronous Communication

  Synchronous when the caller needs an immediate answer to proceed; asynchronous messaging to decouple services, absorb load, tolerate downstream failure, or fan out — at the cost of eventual consistency and more moving parts.

• Replication vs Sharding

  Scale reads first with read replicas; split by feature (functional partitioning) when parts of the schema have different load; shard (horizontal partitioning) only when a single primary can't handle the writes or dataset. Exhaust caching and replicas before sharding.

• SSR vs CSR vs SSG

  SSG for content that's the same for everyone and changes rarely; SSR for personalized or always-fresh pages that still need SEO/fast first paint; CSR for interactive, behind-login app shells. Decide per route, not per app.

• ↑Scope past the prompt — name the migration, the rollout, the on-call cost, not just the happy-path design.
• ↑Quantify. Turn “a lot of traffic” into a number, then size from it: QPS, storage, fan-out.
• ↑Trace the second-order effects — what this forces on the team, the data model, and next quarter.
• ↑Own the option you rejected. Say what you gave up and why it was acceptable here.
• ↑End on the metric. State what you’d instrument to know it’s actually working.

• “I’d use microservices.”

  “I’d start with a modular monolith and split only when a concrete driver appears.”

• “We’ll add a cache.”

  “Reads dominate ~100:1, so I’d cache the hot 20% and accept a few seconds of staleness.”

• “It should scale.”

  “At X QPS the bottleneck is the write path, so I’d shard on tenant id.”

• “I don’t know.”

  “I haven’t hit that in production — here’s how I’d reason about it.”

• You’re not being tested on recall. You’re being tested on how you decide under uncertainty.
• Think out loud. A stated assumption is a gift to the interviewer, not a weakness.
• One clear decision, reasoned end to end, beats three options listed and left open.