How Big Should a Buffer Be?
Smaller Than You Think.
A buffer never makes a line faster than its slowest machine. All it buys is time — and once you see how much time you are actually buying, the right size is usually far smaller than the one people ask for.
The request normally arrives already sized: "we want a bigger accumulator between the filler and the case packer." Sometimes that is right. But the number attached to it is almost always a guess, and guesses about buffers are expensive in both directions — too little and the line stalls, too much and you have paid for floor space, work-in-process and a longer quality exposure that bought you nothing.
What a buffer actually buys
Only one thing: the downstream machine keeps running while the upstream one is stopped. That is the entire mechanism. A buffer adds no capacity, removes no downtime and speeds nothing up. It converts a stoppage that would have propagated into one that stays local.
Which makes the first sizing question arithmetic rather than opinion. If the downstream machine consumes 60 units per minute and the upstream machine is typically down for 4 minutes, then riding out that stoppage completely takes:
Decoupling arithmetic
| Quantity | Value | Meaning |
|---|---|---|
| Downstream demand rate | 60 / min | what drains the buffer |
| Typical upstream stoppage | 4 min | how long it must be covered |
| Buffer to fully cover it | 240 units | 60 × 4 |
That second figure is the one worth sitting with. Doubling the buffer does not double the protection. It extends coverage from a four-minute stop to an eight-minute stop, and if very few of your stoppages last eight minutes, the second 240 units protects almost nothing.
Why the curve has a knee
Plot efficiency against buffer capacity for any real line and the shape is always the same: steep, then flat.
The steep part is the buffer absorbing your common stoppages — the short, frequent ones that make up most of your lost minutes. The flat part is the buffer reaching for rare long stoppages, and it reaches badly: covering a 40-minute failure at 60 units a minute would take 2,400 units of storage. Nobody builds that. They fix the failure instead.
Size on the distribution, not the average. A buffer sized for your mean downtime protects you on roughly half your events, because half of them run longer than the mean. This is the single most common sizing error, and it is why buffers that look adequate on a spreadsheet disappoint on the floor. What matters is the shape of the downtime distribution — and specifically how much of it sits to the right of your coverage.
Which is why you can afford to sweep
Buffer sizes get guessed for a historical reason: sweeping them used to be expensive. When every candidate capacity costs an overnight run, you pick three, and the meeting becomes an argument about which three.
That constraint is gone. Below is a buffer sweep on the Buffer-Options model — the bottling line with inline buffers added, one of the demo models that ships with the trial and the full version. Every capacity from 0 to 100, crossed with every interrupt on the line, ten replications deep, on a 90-day horizon. You can open the same model in the browser sandbox.
What that sweep cost
| Measure | Value |
|---|---|
| Runs in the sweep | 7,770 |
| Wall-clock time | 31.8 seconds |
| Simulated time covered | 1,864 years |
| Rate | 58.68 simulated years / sec |
Nothing here is a number you have to take on trust. The model ships with the product, so the sweep is reproducible: open the Buffer-Options model (Build Sequence 4 - Buffer Options.aidos), choose the Buffer Tradeoff experiment on Parameter Set 0, set 90 days and 10 replications, seed 123, and run it. Your wall-clock time will differ with your machine; the curves will not.
Take the timing as one measurement, not a specification. It moves with the model, the machine and the run length. What generalizes is not the number but its consequence: when a full sweep finishes while you are still reading the question, guessing a buffer size is a choice rather than a constraint — and there is no reason to bring three candidates to a meeting when you can bring the curve.
That vertical spread is the finding. Sliding right along any single curve is what buying storage does for you. Stepping up to a higher curve is what removing an interrupt does. On this line the second move is worth more than the first at every capacity — which is the model's own teaching point: buffers absorb short interrupts, but the dominant loss is a long stoppage on the constraint itself, and no amount of storage fills that. Fix the machine, not the flow.
The real trade-off is buffer versus reliability
Every buffer question is secretly a comparison. You can spend money on storage, or you can spend it on making the upstream machine stop less often. Both raise efficiency. They cost very different amounts and they fail in different ways.
- Buffer — capital, floor space, permanent work-in-process, and a longer exposure window if you make bad product. It treats the symptom, reliably.
- Reliability — usually harder, sometimes cheaper, and it compounds: fixing the failure helps every downstream station at once, not just the next one.
- The trap — a generous buffer hides the failure it is absorbing. The line runs acceptably, the root cause never gets attention, and the buffer becomes permanent.
This comparison is exactly what the Buffer Tradeoff experiment exists to make. It sweeps a buffer's capacity across a range while selectively dropping interrupts, so you can read added storage and removed downtime on the same axis and see which one your line actually responds to.
How to get the number for your line
- Start smaller than you think. Model minimal buffering first. Buffers added early hide the behavior you are trying to see, and a model full of generous buffers will tell you the line is fine.
- Put buffers where storage physically exists. Not at every connection — overuse obscures the real drivers of flow.
- Sweep, don't guess. Run the tradeoff experiment and look for the knee. Then look at the box-and-whisker output too: a capacity that raises the average while leaving the spread wide is buying you a better mean and the same bad weeks.
- Check what it is protecting. If one interrupt dominates the benefit, price fixing that interrupt before you buy the storage.
And remember that transport can be storage. An accumulating conveyor is a buffer with a travel time attached, which means some of the capacity you are about to build may already be on the floor.
Related: Starved vs blocked · Find the real bottleneck · Buffers in the ReliaSim docs
Find your knee
The sandbox runs a bottling line in your browser. Change a buffer capacity and watch how much — or how little — efficiency moves.
Open the sandbox → How the method works