First Principles
"We need Redis" names a solution. First-principles thinking asks what problem it solves — repeated reads are slow — and only then evaluates options, of which Redis is one. The move is not "avoid tools"; it is "find the requirement before you choose".
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A requirement arrives already containing its solution. How do you get back to the problem underneath it, so that the solution can be chosen rather than inherited?
The ticket says "add Redis caching to the product catalog". You have not used Redis. You are about to spend the week learning it, and something about the ticket bothers you: nobody has said what is slow.
Do what the ticket says. It came from someone senior, Redis is a known tool for a known purpose, and learning it is a good use of a week. Questioning the ticket feels like arguing with experience.
The week produces a working Redis integration and no measurement. Whether the catalog is faster is unknown, because "slow" was never defined; whether it was the catalog that was slow is also unknown.
- The week produces a working Redis integration and no measurement. Whether the catalog is faster is unknown, because "slow" was never defined; whether it was the catalog that was slow is also unknown.
- The cache introduces a second copy of every product, and the first price change that does not appear on the site is the moment the team discovers that invalidation was part of the ticket and nobody wrote it.
- Because the requirement was a technology, the alternatives were never listed. A missing index, an N+1 query and a page that fetched every product to show ten were all candidates, and two of them were an hour's work.
- The next ticket says "add Kafka". The habit of building what the ticket names has been reinforced, and the system accumulates components whose problems nobody can state.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Separate the claim from the requirement. A claim names a thing — Redis, Kafka, microservices. A requirement names a property the system must have — reads of the catalog complete quickly enough that the page feels instant. Every claim was once someone's answer to a requirement; the move is to recover the requirement.
- Ask "what problem does this solve?" and refuse an answer that is another technology. "Redis solves caching" is a claim about Redis; "repeated reads of the same products are slow because each one hits the database" is a requirement with a mechanism in it, and it can be measured.
- With the requirement recovered, list the ways of meeting it — including the one that was proposed. For slow repeated reads: an index, a fixed query, an in-process cache, a shared cache, a materialised table. Each has a cost and a failure mode; the proposed one is now one row, not the whole table.
- Choose on evidence. Measure the requirement — is the read actually slow, and where — before choosing the row, because the cheapest option that meets a measured requirement is almost never the one the ticket named, and occasionally it is. The lesson is not "no Redis"; it is "Redis, when the requirement says so" (Evaluating a Technology).
Redis, climbed
The why ladder from the module description, with all four required parts: the rungs, the real requirement, the simpler thing that meets it, and the case where Redis was right after all. The last part is the difference between first-principles thinking and reflexive minimalism.
“We need Redis for the product catalog.”
- ↓Why Redis? To cache the catalog.
- ↓Why cache it? Repeated reads of the same products are slow.
- ↓Why are they slow? Measured: the product page runs one query per product for its category — an N+1 — and each query is fast on its own.
the claim was right when Reads are already single, well-indexed queries, the same products are read far more often than they change, several servers need to share the cache, and the measured read latency still misses the requirement. Then a shared cache is the cheapest thing that meets it — and cache invalidation is now a requirement to write down.
The options, once the requirement exists
With the requirement recovered, the proposal becomes one row. The matrix scores the rows on the axes that move; the caveat says what the numbers cannot.
| Option | Simplicity | Performance | Reliability | Cost | Maintainability | Note |
|---|---|---|---|---|---|---|
| Fix the query (join) | Meets the measured requirement; adds nothing. | |||||
| In-process cache | Fast; per-server; stale until the entry expires; wasted when there are many servers. | |||||
| Shared cache (Redis) | Fastest and shared; a new service to run, a second copy to invalidate, a new failure mode. |
caveat The scores are ordinal — "the join is simpler than Redis" — and say nothing about magnitude. Performance for the join is 4 only because the N+1 was the measured problem; on a different measured problem the same row could be a 1, and the matrix would have to be rebuilt from that measurement.
Claim or requirement?
The sentence that arrives is either a claim or a requirement, and the two are answered differently. The comparison shows the same ticket written both ways, and why the second can be evaluated and the first cannot.
"Add Redis caching to the catalog." Evaluable only as: was Redis added? Yes. Done.
"The product page loads within the demo's tolerance at demo traffic; currently it does not, and the query log shows one query per product." Evaluable as: does the page now load within tolerance, by which change, and what did the change add to the system?
A claim can only be satisfied by itself. A requirement can be satisfied by several things, compared on cost, and checked by a measurement — which is what makes it engineering rather than installation.
How to do it
Most important first.
- When a requirement names a technology, write the sentence "we need X because ___" and fill the blank with a property of the system, not with what X does.
- Measure the property before designing. If "slow" has no number, the first task is to get one, not to add a component (Non-Functional Requirements).
- List at least three ways to meet the requirement, including the one proposed and the one that involves adding nothing.
- For each, write what it adds to the system and what it does when it fails — the complexity ledger (The Complexity Ledger).
- Choose the cheapest that meets the measured requirement, and write down what evidence would justify moving to a heavier one.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "Add Redis to the catalog." Because — after asking — the product page takes noticeably long to load under the demo traffic. Measured: the page makes one query per product to fetch its category name. The requirement is "the product page loads quickly at demo traffic"; the mechanism is an N+1 query. Options: join the category in the query; cache per product in process; Redis. The join fixes it in an hour with nothing added. Redis stays on the list with the note: "if the catalog outgrows one server's memory, or several servers must share the cache".
- "Use Kafka for order events." Because the checkout waits for the confirmation email to send. Requirement: the customer sees confirmation without waiting for email. Options: send the email in a background job from a table; a simple queue; Kafka. A job table and a worker meet it with one moving part. Kafka stays on the list for "when several consumers need the same ordered stream and replay". See The Why Ladder for the full climb.
- The AI assistant, asked "how do I add Redis to my catalog?", produced a correct integration and never asked what was slow — because the question contained the answer. Asked "my product page is slow, here is the query log", it pointed at the N+1 first. The tool amplified whichever question it was given (Good Tool Use).
How you know it worked
What now exists that did not before, and what question you can now ask.
- The requirement is written as a property of the system with a measurement attached, and the technology is one row in a list of ways to meet it.
- You can say what the proposed technology would add and what it does when it fails, and so can the person who proposed it.
- The chosen option is the cheapest that meets the measured requirement, and the note says what evidence would justify the next one.
- The ticket that names a technology now triggers a question rather than a week.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What problem does this technology solve here — stated as a property of my system, not as a feature of the tool?
- ?Have we measured that property, and where exactly is it failing?
- ?What are three ways to meet it, including adding nothing?
- ?What would the proposed tool add to the system, what does it do when it fails, and what evidence would make it the right choice?
What can go wrong
- First principles as contrarianism: every proposal is climbed down to a requirement and rejected, including the ones that were right. The device ends with
justifiedWhenfor a reason — sometimes the person who said Redis had measured. - Climbing forever. "Why do reads need to be fast?" — "so customers stay" — "why?" — "revenue". Stop at the first rung that is a measurable property of the system; below that is the business, which is not being redesigned.
- Recovering the requirement and then guessing the mechanism. "Repeated reads are slow" without a query log becomes "so we need a cache" — a new claim with no evidence, one rung down from the old one.
- Applying the move to a team that has already done it. The senior engineer who wrote "Redis" may have measured, listed and chosen last quarter; ask for the evidence before re-deriving it.
- Asking "why" of a senior engineer's ticket costs social capital, and on a team where the answer is "I measured, here is the graph" it was spent for nothing but a lesson.
- Measuring before building delays the fix. When the problem is obvious and the fix is an index, the measurement was a formality; the trouble is that "obvious" is exactly what the reflex also feels like.
- The simpler option is sometimes a dead end that the heavier one was not: an in-process cache that later has to become a shared one is two migrations instead of one. Reversibility is part of the choice (Reversible vs Irreversible Decisions).
- "First principles means never using Redis." It means using it when the requirement, measured, says so — and being able to state the requirement. Some catalogs need a shared cache on the first day; the move finds those too.
- "This is premature-optimisation advice." That slogan says do not optimise before measuring; this move says do not choose a component before recovering the requirement. They overlap when the component is an optimisation, and differ when it is not — Kafka is not an optimisation.
- "The ticket author was wrong." The ticket author compressed a requirement into a solution, which is what experienced people do to save words. The move decompresses it; it does not overrule it.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALClaim → requirement → options → evidence applies to any proposal that names its solution, from a library choice to an organisational one.
- TEAM-SPECIFICA solo learner has to climb every ticket because nobody else has; on a team with an architecture record, the climb is often already written down and the move becomes reading it — and noticing when it is missing.
- ILLUSTRATIVEThe N+1 query, the demo traffic and the hour-long fix are invented to show the shape of the move; measure the real page.
Where the depth lives
This domain asks the question and hands the answer off by name.