Amdahl's Law

The speedup from parallelising is capped by the part that cannot be parallelised.

However many processors you add, the serial part of the work caps the speedup.

To an executive

Adding people or machines will not speed up work that waits on a single step, such as one approval. Fix the waiting step before buying more capacity.

To an engineer

Measure the serial fraction of your workload before adding parallelism. If a tenth is serial, speedup tops out at ten times, however much hardware you add.

The idea

Gene Amdahl made the argument in a short 1967 conference paper: the part of a workload that must run serially limits how much faster parallel hardware can make the whole.

If a fraction s of the work is serial, the best possible speedup with N processors is 1 / (s + (1 − s) / N). As N grows, this approaches 1 / s. So if 10% of a task is serial, no amount of parallel hardware can make it more than ten times faster. The serial part dominates as resources are added.

The same arithmetic applies to organisations. Adding teams cannot speed up work that waits on a serial step, such as a central approval or a single release train.

Why it works

The serial part does not shrink when you add capacity. Parallel work gets faster with more resources; serial work takes the same time however many you add.

Diminishing returns arrive early. With 10% serial work, going from 1 to 10 processors gives roughly a fivefold gain; going from 10 to 100 adds much less.

It tells you where to spend effort. Once the parallel part is fast, only shrinking the serial part helps.

Where it applies

Scaling out services and batch jobs, where global locks, single-writer databases or a final aggregation step stay serial.
Data pipelines, where one stage cannot be split across workers.
Build and test pipelines, where some steps must run in sequence.
Delivery organisations, where a shared approval or integration step serialises many teams' work.

How to apply

Measure the serial fraction. Profile the workload and find the steps that cannot run in parallel.
Calculate the ceiling. Use the formula to see the best speedup before buying more capacity.
Shrink the serial part. Partition locks, split aggregation into a tree, or remove coordination steps.
Re-measure. After each change, check where the remaining serial time sits.

Example scenario

A nightly data pipeline was moved to a much larger cluster to finish faster. Runtime fell only modestly. Profiling showed that a final single-threaded aggregation step now took most of the time, and no extra nodes could help it.

The team rewrote that step as a tree reduction, with partial aggregates computed in parallel and merged in a few rounds. Runtime dropped far more than the extra hardware had managed, and they could scale the cluster back down.

Questions to ask

What fraction of this work is inherently serial, and have we measured it?
Given that fraction, what is the best speedup we could ever get?
Are we adding parallel capacity to a problem that is limited by a serial step?

When not to use it

Workloads that grow with capacity, where you use more processors to do more work in the same time rather than the same work faster; Gustafson's view fits better there.
Systems where coordination costs grow with scale, where the Universal Scalability Law gives a more realistic, and more pessimistic, picture.

How it misleads you

Assuming the serial fraction is fixed. Redesign can often shrink it dramatically, which changes the ceiling. The law also assumes perfect parallelism for the rest of the work; real systems pay coordination costs, so actual speedup is usually lower than Amdahl predicts.