The question this answers
How do I get from what the application does to what infrastructure it needs, without a product name appearing early?
A team is about to make a dozen infrastructure decisions at once — compute model, network boundary, database, secrets, deployment, monitoring — and has no principled order in which to make them.
A repeatable derivation that produces a defensible design: every component traceable to a stated application requirement, and every requirement traceable to a component or to an explicit, written acceptance of risk.
The derivation, in one direction only
The method is deliberately mechanical. Take a statement about the application, restate it as a statement about infrastructure, then choose the smallest component that satisfies the infrastructure statement. The middle step is the one teams skip, and skipping it is what lets a product name arrive before a requirement does.
"Users upload profile photos" is an application statement. The infrastructure statement is: *binary blobs of a few megabytes, written rarely, read often, must survive instance replacement, must be served without the application process on the read path.* Only now does object storage become the obvious answer — and only now is it obvious why a database BLOB column and a local disk are both wrong, which is the part that survives into the next design.
Run in reverse, the same case produces "we need S3" with no articulated reason, and then a year later nobody can say whether moving the photos into the database would be fine, because the requirement was never written down. The derivation is not bureaucracy; it is the only thing that makes the decision reviewable later.
| The application says | Which means, in infrastructure terms | So the smallest thing that does it |
|---|---|---|
| "Users upload profile photos" | Few-MB blobs, write-rare read-often, must outlive any instance, served off the app's critical path | Object storage with direct signed uploads — see Object Storage |
| "Checkout must not double-charge" | Request identity must survive a retry across instances; state must be transactional | A relational database with a uniqueness constraint; no infrastructure component fixes this |
| "A restart must not be a visible outage" | At least two instances behind one address, and a drain period before termination | Load balancer + 2 instances + Graceful Shutdown: The 502 Spike Nobody Investigates |
| "The report takes 90 seconds" | Work must outlive the HTTP request, and must be retried if a worker dies | A queue and a worker pool, and a way to tell the client the result later |
| "We handle EU health data" | Data must stay in a stated jurisdiction; access must be attributable to a person | Region selection plus an audit trail — see Regions and Availability Zones, Audit Trails |
| "Traffic is 20x on Monday mornings" | Capacity must change faster than a human can react, and new capacity takes minutes to be useful | Metric-driven scaling with warm headroom — see Autoscaling |
What the workload is, in six numbers
Before any component is chosen, six properties determine almost every subsequent decision. They are cheap to estimate and they are what a good infrastructure interview probes for, because a candidate who asks for them is deriving and a candidate who does not is pattern-matching.
Shape (synchronous request/response, background batch, streaming, or long-running job) decides the compute model. Load and its variance decide whether capacity is fixed or elastic. State decides everything about failure: a stateless process can be killed at will, a stateful one cannot. Latency tolerance decides how close to the user things must be. Consistency and durability requirements decide the data layer. Compliance decides the region and the audit path.
Note the ordering property: these six constrain each other. A workload that is stateless, bursty and latency-tolerant has many good answers. One that is stateful, steady, latency-sensitive and jurisdictionally constrained has very few, and discovering that early saves a design cycle. The Choosing a Compute Model tree is this same reasoning applied to one decision.
- Shape — request/response, batch, streaming, or long-running. Decides the compute model before anything else.
- Load and variance — steady 40 req/s and bursty 40→4,000 req/s are different systems with the same average.
- State — what cannot be recreated by rerunning the code. This is the only part of the system that genuinely cannot be treated as disposable.
- Latency budget — a 20 ms p99 target and a 2 s one lead to different regions, different caches and different databases.
- Durability and consistency — how much recent work may be lost, and whether a read must see the last write. See RPO & RTO.
- Compliance and residency — which jurisdictions the bytes may sit in, and who must be able to prove who touched them.
Reverse derivation is expensive, and the bill shows it
Component-first design has a characteristic cost signature: a large fixed baseline that exists regardless of traffic, because each component was adopted for a capability nobody measured. Three control-plane nodes, a NAT device per zone, a message broker cluster and a cache tier all bill by the hour whether or not the workload uses them — and a workload doing 40 requests per second uses almost none of it.
The specific incident that makes this concrete: a team adopted a managed streaming platform to "future-proof" event handling, used it for a single welcome-email topic, and paid a broker-hours baseline every month for three years. The email volume never justified anything more than a database table and a cron job. Nobody removed it, because removing infrastructure requires proving nothing depends on it, and proving a negative in a system nobody fully understands is a project.
Derivation flips the signature: usage-shaped spend that tracks traffic, and a small fixed floor. That is not automatically cheaper at every scale — a steady, predictable, high-volume workload is often cheaper on reserved fixed capacity — but it is cheaper *while you are finding out what the workload is*, which is when most of these decisions get made. See Fixed vs Variable Cost.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- The derivation runs application requirement → infrastructure requirement → capability → component → product name, and only in that direction.
- Six workload properties — shape, load variance, state, latency budget, durability, compliance — constrain almost every later decision.
- The middle step, restating the requirement in infrastructure terms, is what makes the decision reviewable a year later.
- Component-first design produces a large fixed cost baseline that is invisible in the design review and obvious in the invoice.
- A requirement you choose not to satisfy is a legitimate outcome, provided it is written down with the trigger that would change the answer.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Write the application behaviour in the words a product owner would use, without infrastructure vocabulary.
- • Estimate the six properties. Estimates are fine; the point is to notice which ones you cannot estimate at all, because those are the risks.
- • Restate each behaviour as an infrastructure requirement with a number in it wherever possible — "must survive one instance restart", "must not lose more than 5 minutes of writes".
- • For each requirement, list the candidate components in increasing order of complexity and take the first one that satisfies it.
- • Record the requirements you did not satisfy and the observable event that would force you to revisit them.
- • Keeping the derivation current: the document is worthless the moment the workload changes and nobody updates the six properties.
- • Re-running the derivation at each significant scale step — the answers change at 10x, and the old answer stops being reviewed precisely because it once was correct.
- • Defending the deliberate gaps in design reviews, repeatedly, against the reflex that more components means more rigour.
- • Estimated properties that were wrong by an order of magnitude — usually load variance, which is under-estimated because averages hide bursts.
- • A requirement that was real but unstated, most often compliance or data residency, discovered during a customer security review after the design has shipped.
- • Derivation performed once, then treated as permanent; the workload became stateful and the design still assumes disposable instances.
- • Correct derivation, ignored organizationally: the design is right and the team ships the reference architecture anyway.
- • The derivation itself does not scale by traffic; it scales by the number of distinct workloads, and past roughly a dozen it needs to become a small set of standard shapes rather than a per-service exercise.
- • Load variance is the property that changes fastest and invalidates the most decisions — a workload that becomes bursty needs a different compute model, not a bigger instance.
- • Organizational growth changes the answers even when the workload does not: six teams sharing one deployment pipeline forces boundaries that two teams did not need.
- • Compliance and data residency belong in the six properties, not in a later review — retrofitting a jurisdiction constraint means moving data, which is the most expensive infrastructure change there is.
- • The derivation should produce an explicit trust boundary and an explicit identity for the workload, before any component is named.
- • Deriving from the workload naturally produces least privilege: you know precisely which resources the application touches, because you listed them — see Least Privilege in Infrastructure.
- • Derived designs skew usage-shaped; catalogue designs skew fixed. Neither is universally cheaper, but only one of them is cheap while the workload is still unknown.
- • Each undeclared component contributes a permanent floor to the bill and a permanent share of the team's attention.
- • The cost of the derivation itself is a day of engineering time, against months of committed spend.
- • Track whether the six properties still match reality — a p99 that has doubled, or a peak-to-mean ratio that has tripled, invalidates decisions silently.
- • Utilization per component is the cheapest audit: a component whose utilization is near zero was probably never derived from anything — see Idle Capacity: Headroom or Waste?.
- • The signal that lies: a healthy dashboard on a component nobody uses. Health says it is running, not that it is needed.
- • Adopting an opinionated platform (a PaaS, or your organization's existing golden path) and deriving only where you deviate from it. For most teams this is strictly better than deriving from scratch, and the derivation still tells you where the deviation is justified.
- • Copying a design from a comparable system in the same organization, provided you check the six properties match — a reference architecture from *your* company at *your* scale is far better evidence than one from a vendor blog.
- • For a genuinely small workload, skip the exercise and use a managed application platform. The derivation exists to prevent over-building; do not let it become over-building of its own.
- • Costs design time before any code runs, and surfaces disagreements early — which is the point and also why it feels slow.
- • Produces designs that look under-built to reviewers who expect a reference architecture, and you will have to defend that repeatedly.
- • Requires estimates the team may not have; the honest response is to note the uncertainty, not to substitute a component for it.
What people believe, and what is true
Deriving means building everything yourself.
The derivation frequently lands on a managed service — it just lands there for a stated reason, which is what makes the choice defensible when the bill or the outage arrives.
You can derive once and be done.
The six properties drift. Load variance and state are the two that change fastest, and both invalidate compute-model decisions.
If a big company runs it this way, it is the safe choice.
Their six properties are not yours, and neither is their platform team. A design is only safe relative to the organization that operates it.