The Staff mindset: "it depends" is the answer

This is the one reframe the whole course hangs on. Junior engineers hunt for the right answer. Staff engineers know there's rarely a best, only a position on a trade-off, chosen on purpose and defensible. Get this and every lesson after it clicks.

"What's the best database?"

The moment you ask it that way, you've told the room you think architecture is a lookup: find the winner, memorise it, deploy it. But there is no winner. There's Postgres for this, Cassandra for that, and a reason for each. The reason is the job.

Best is only a word after you name the constraint. Best for consistency? Best for write throughput? Best for a team of three who can't run a cluster? Different answers, every time.

Two engineers, one question

• Junior framing "What's the best X?" Searches for a single right answer, copies the popular default, defends it with "everyone uses it."
• Staff framing "What am I trading, and for what?" Names the axis, picks a position on purpose, and can say the price they chose to pay.

Same input, opposite move. One looks for a fact to retrieve. The other makes a decision and owns it.

Architecture is choosing where to sit

Every serious design choice is a trade-off axis with two ends. You can't have both ends at once, so you pick a spot on the line, on purpose, and you can say why you sit there and not somewhere else. That's it. That's the job.

Not "which tool wins." Which end of each trade-off does this problem need, and what am I giving up to get it? A design is a set of those positions, held on purpose.

"SQL or NoSQL?"

✗ The junior answer

"NoSQL, it scales better." Copies a default they read once. If you ask why, the answer is "it's what big companies use." No axis named, no price acknowledged.

✓ The staff answer

"The orders table needs multi-row transactions and I'll query it a dozen ways I can't predict, so I'll pay for a relational store and give up easy horizontal sharding. If write volume ever forces it, I'd revisit." Axis named. Trade owned.

Notice: the staff answer might also land on SQL. The difference isn't the pick. It's that one of them can tell you what they gave up to make it.

Almost every decision lives on one of six axes

Here's what nobody tells you early: you don't face a thousand different choices. Under the surface, nearly every system-design call is a position on one of six recurring trade-offs.

• Consistency ↔ Availability
• Latency ↔ Throughput
• Read ↔ Write
• Space ↔ Time
• Coupling ↔ Flexibility
• Cost ↔ Everything

Don't worry about learning these yet. Module 2, The 6 Core Trade-offs, maps all six properly, one per lesson. For now, just believe they exist: the whole field of "design" is smaller than it looks.

"It depends" is where the answer starts

Juniors say "it depends" and stop, because they don't know what it depends on. That reads as ducking the question. Staff engineers say "it depends" and then keep talking, because the interesting part is naming exactly what it depends on.

• Cop-out "It depends." (silence)
• The real answer "It depends on whether this data can tolerate being a second stale. If it can, I lean availability; if it's money, I don't."

The skill this course builds isn't a bigger list of answers. It's the reflex to hear "design X" and immediately ask "depends on what?", then answer that.

Here's that reflex as a shape. A question comes in, you name the factors it actually depends on, and those factors push you toward a choice you can defend, one that comes with a stated trigger for when you'd change your mind:

The point isn't the box labelled "choice," it's the box labelled "trigger to revisit." A staff answer names the condition that would flip it, not just the pick.

There's rarely a best. There's a position you chose on purpose, and can defend

1. Stop hunting for the right answer. "What's the best X?" is the junior question. It has no answer until you name the constraint.
2. Architecture is choosing a position. Pick an end of each trade-off on purpose, and be able to say what you gave up.
3. "It depends" is the start, not the end. The whole answer is naming what it depends on, then answering that.
4. Next: lesson 0.4 · What you'll be able to design by the end, the payoff, so you can see where this reflex takes you.