The 6 core trade-offs.

There are no right answers in architecture. There are only positions on a handful of axes, chosen on purpose. Tonight we name all six, so you stop guessing and start deciding out loud.

The run sheet.

You'll be able to…

"It depends" is the answer.
The skill is saying on what.

Junior engineers want the right database. Staff engineers know the database is downstream of a position they took on an axis. Architecture is choosing where to sit on each trade-off, deliberately, and being able to say why.

Six axes. Almost every decision is on one of them.

Decide what happens when the network splits.

CAP is the soundbite; PACELC is the useful form. Read it as one question with two branches, and notice you're paying somewhere on both.

flowchart TB
  P{"Network partition
happening?"}
  P -- "Yes · the P" --> PICK{"Pick one,
you can't keep both"}
  PICK -- Availability --> AP["Cart · feed · presence
serve stale, reconcile later"]
  PICK -- Consistency --> CP["Ledger · inventory · auth
refuse rather than be wrong"]
  P -- "No · the E (Else)" --> ELSE{"Even healthy,
still trading"}
  ELSE -- Latency --> L["answer fast,
guarantee weaker"]
  ELSE -- Consistency --> C["guarantee strong,
wait a little longer"]
  classDef ap fill:#DCEBFE,stroke:#1F2937,color:#0E1726;
  classDef cp fill:#FEF3C7,stroke:#1F2937,color:#0E1726;
  classDef ask fill:#ffffff,stroke:#1F2937,color:#0E1726;
  class AP,L ap;
  class CP,C cp;
  class P,PICK,ELSE ask;
        

Batching buys throughput with someone's latency.

Every batch, queue, and buffer raises requests-per-second and adds delay to the request that waits for the batch. They are not the same number and they do not optimize together.

You can make reads cheap or writes cheap. Pick the hot one.

The classic case is the feed. Same post, two ways to spend the work, and the bill just moves between the write path and the read path.

flowchart LR
  POST(["New post"])
  POST --> FW["Fan-out on WRITE
copy into every follower timeline now"]
  POST --> FR["Store once
normalized, do nothing extra"]
  FW --> FWR(["Read = 1 cheap lookup
but a celebrity's write fans out to millions"])
  FR --> FRR(["Read = join across everyone you follow
cheap writes, slow reads"])
  FWR --> HY{"Hybrid:
push for most,
pull for celebrities"}
  FRR --> HY
  classDef w fill:#D6F5E3,stroke:#1F2937,color:#0E1726;
  classDef r fill:#FEE4E2,stroke:#1F2937,color:#0E1726;
  classDef h fill:#FEF3C7,stroke:#1F2937,color:#0E1726;
  class FW,FWR w;
  class FR,FRR r;
  class HY h;
        

Spend storage to buy latency, and say what staleness you bought.

Caches, indexes, materialized views, denormalized copies, bloom filters: all the same move. You hold extra bytes so you can skip computation. The hidden cost is rarely the bytes, it's the staleness and invalidation.

Couple by default. Split on a real axis of change.

A monolith is cheap to build, deploy, and reason about, and it couples everything's release and scaling together. Services buy independent deploy and scale, and charge you network calls, partial failure, and distributed data. Splitting for the org chart, not a real axis, is how you get a distributed monolith.

Every extra 9 and every saved millisecond has a bill.

Performance, reliability, and time-to-market are all bought with money or time. Active-active multi-region roughly doubles infra for one more 9. Build-vs-buy is this axis. The staff move is tying the spend to a business number, not "best practice."

"Reads are slow, let's add a cache."

One sentence, three axes moved at once. Staff engineers don't say "add a cache," they account for all three out loud.

Axis → Position → Consequence → Trigger.

Four sentences. Run them on any decision and you sound like you chose it, because you did.

Locate a real decision on the axes.

Bring a choice from your current system: a cache, a queue, a split, a database pick. We'll do one together, then you run the four sentences on yours and drop the axis + position in the chat.

Four ways engineers dodge the trade-off.

Six axes, one sentence each.

Consistency↔Availability · Latency↔Throughput · Read↔Write · Space↔Time · Coupling↔Flexibility · Cost↔Everything. For every call: name the axis, take a position, own the consequence, set the trigger.