First Principles Thinking
Reasoning from what must be true rather than from what is usually done — the technique for problems where precedent is unavailable or misleading.
Definition
Decomposing a problem to the constraints that are actually fundamental — physics, mathematics, the domain's invariants — and reasoning up from there, rather than reasoning by analogy to what others have built.
Where it matters most
When the precedent comes from a different context. Copying an architecture because a large company published it is reasoning by analogy, and it fails when their constraints differ from yours — which they almost always do, in scale, team size, or workload shape.
When something is asserted as impossible. "We cannot go below 200 ms" invites the question: what is the floor? Speed of light in fibre for the round trip, plus serialisation, plus the actual work. If those sum to 40 ms, the remaining 160 is architecture, not physics.
When a cost seems inevitable. What is the theoretical minimum work required, and where is the difference going?
The fundamental constraints worth knowing
- Speed of light. Roughly 150 ms round trip intercontinentally in fibre. Unimprovable, and it bounds every synchronous cross-continent design.
- Little's Law. Concurrency equals arrival rate times latency. Not a heuristic — an identity.
- Queueing behaviour. Waiting time rises non-linearly as utilisation approaches saturation.
- CAP. During a partition, consistency or availability, not both.
- Information theory. You cannot compress below entropy.
- Coordination costs a round trip. Any agreement between machines requires at least one.
Reasoning from these produces answers that hold regardless of technology choice, and they are stable in a way that vendor benchmarks are not.
The method
- State the goal in measurable terms.
- List every assumption in the current approach.
- Ask of each: is this a law, a constraint, or a convention? Most are conventions.
- Reason up from what is genuinely fixed.
Step three is where the value is. "We need a database" is a convention; "we need durable state with these access patterns" is closer to the requirement, and it admits answers a database does not.
Where it is misapplied
Rebuilding solved problems. First principles reasoning tells you that a queue is possible; it does not mean you should write one. Use it to understand constraints and evaluate options, not as a licence to ignore accumulated engineering knowledge.
Interview question
"A team says 200 ms is the minimum achievable latency. How would you check?"