Appendix E · The web service model, in full

A web service and the data it keeps, on a fleet of Linux hosts, sized from a stated busy hour and costed over five years. No product is named and none is implied: what is on this page is a structure, and the numbers in it are placeholders for yours.

This is the model the chapters build a few nodes at a time, and it is a sizing model by the rule and by its shape. Most of it is accounting identity and physics: requests times CPU time per request, watts times hours times price, capital plus running cost over a horizon. That is the structure the introduction says sampling the inputs is sufficient for. But it carries one measured constant and six ceilings, so scripts/verify-models.py classifies it a sizing model and holds it to the stricter rules. That is the right call: a compression ratio belongs to a codec, and a fleet asked for more than it can serve does not slow down proportionally. Appendix F is the book’s second model, and shows what one looks like when a whole chain of it has not been measured.

The graph

Colour is kind: inputs, derived quantities, the one measured constant, and the ceilings. An input’s border says what it is claiming: solid for a fact, dashed for a vendor’s claim, dotted for an assumption. Arrows run from cause to effect, and every node sits immediately to the right of the last thing it depends on.

Read two things off it directly. The graph is wide at the left and narrow at the right: many quantities collapsing into a handful of answers, which is what makes a single wrong input so hard to spot downstream. And three separate chains reach the host count: the request rate, the working set and the data on disk. That is ch10’s whole subject.

Every formula

The graph above, as text: every derived quantity and every ceiling, with the formula the file gives it and the chapter that added it. The table is rendered from the file, so it cannot disagree with it.

Source — models/web_service/model.yaml and its build order

The outputs

Source — web_service-reference · every input on a slider

Where each ceiling sits

Source — web_service-reference · every input on a slider

The verdict column is about the plan; the last two columns are about the world. A design that is under its hard limit and inside the margin it declared has not failed. It has spent the reserve it was keeping for the failure it has not had yet (ch11).

What moves the answer

Source — web_service-reference · every input on a slider

Each bar swings one input across the middle of its own declared range with everything else held still. The ordering is the useful part: it says which input to go and measure first (ch19). It is also a one-at-a-time analysis, so an input whose effect only appears in combination with another gets a short bar here and can still be the thing that sinks you.

Every bar is a cost input, and the demand side is not here at all. No request rate, no growth rate, no records held. That is not an omission in the chart. The total prices the fleet that was bought, and the fleet is hosts — a number somebody decided, not one the model derived. More data does not buy more hosts by itself; it makes the fleet you have too small, and the model says so through the disk and cache ceilings rather than through the bill. Drag records held, day one on the interactive page and watch the recommendation and those two ceilings move while the total sits still. The panel names, for any input, which outputs it can move and which it cannot.

To see demand move the price you re-decide the fleet, which is what the second scenario below does.

The answer as a distribution

Unit cost rather than total cost, because it is the figure that behaves least like people expect. A fleet bought for growth that then arrives is cheap per request; the same fleet is expensive if the growth never comes. The distribution carries both futures, and a single number carries neither.

Where the inputs came from

Source — web_service-reference · every input on a slider

Source — web_service-reference · every input on a slider

One measured constant, and its conditions are on the row: a compression ratio belongs to a codec and a body of data, and this one was measured over a synthetic corpus of application records that this repository generates. The method transfers; the number does not. Point the runner at a sample of your own records (ch03).

Two scenarios, side by side

Source — web_service-reference and web_service-sized_for_growth · every input on a slider

The left column buys what the point estimates recommend. The right buys for the growth case the model thinks is plausible but not expected. The difference in capital is a number, and so is the difference in how often each ceiling breaks. Choosing between them is a judgement somebody has to make and defend, which is ch21 · A TCO for a finance audience.

What this cannot tell you

Whether the fleet is the right one. The model prices hosts, and hosts is a decision. Every figure on this page is conditional on it, and nothing here argues for the number: the reference scenario takes the recommendation at the point estimates, which is how the decision is usually taken and is not the same as it being right. The ceilings say whether that fleet survives the model’s futures; they cannot say whether a different fleet would have been a better buy. That comparison is a second scenario and a judgement, which is ch21.

What the structure leaves out. The chains here are demand, memory and disk, and they meet only at the host count. Nothing connects a request to the record it writes, so a model where traffic and data grow together cannot be told from one where they do not — and this one assumes they do, in a single correlation, rather than deriving it. There is no tier that fails differently from the others, no request that costs more than its neighbour, and no second site. Sampling the inputs harder will not find any of that: an omission is not a wide interval, it is a chain that was never drawn (ch20).

Whether five years is the right horizon. It is a decision too, and it sets how much of the total is capital and how much is running cost. A different horizon does not just scale the answer; it changes which half of the bill the argument is about (ch15).

Running it yourself

python3 -m bench.run_models --model web_service     # evaluate, sample, stamp
python3 scripts/verify-models.py                    # units, provenance, ceilings, shape
python3 scripts/render-figures.py                   # re-render every figure above
python3 -m pytest tests/test_models.py              # the reference outputs, asserted

Every figure on this page came from bench.run_models. verify-models.py refuses a model that does not typecheck, and tests/test_models.py is what stops any of it changing silently.