Amdahl's Law
Also known as: Amdahl's argument, speedup limit
Amdahl's Law bounds the speedup available from parallelism: if a fraction s of the work is inherently serial, maximum speedup is 1/s no matter how many processors you add. A workload that is 5% serial cannot go more than 20x faster, however wide the machine.
Last reviewed · Part of the Architecture Glossary
In practice
The numbers are unforgiving:
| Serial fraction | Max speedup | Speedup at 16 workers |
|---|---|---|
| 1% | 100x | 13.9x |
| 5% | 20x | 9.1x |
| 10% | 10x | 6.4x |
| 25% | 4x | 3.4x |
The architectural reading: the serial fraction in a distributed system is rarely CPU. It is the shared thing everyone must touch — the single-writer table, the distributed lock, the sequence generator, the config service, the one queue partition that preserves ordering. Adding service instances scales the parallel part and leaves that untouched.
Gustafson's Law is the useful counterweight: if you grow the problem size along with the machine, the serial fraction often shrinks as a proportion, and near-linear scaling returns. Which law applies depends on whether you are making a fixed job faster or absorbing more load.
When it matters
Deciding whether horizontal scaling will help before buying the instances; finding the real bottleneck when doubling the fleet produced a 15% improvement.
Common mistake
Parallelising the part that is easy to parallelise. If 70% of wall-clock time is one un-shardable database write, optimising the 30% is capped at a 1.4x total win — and it is usually where all the effort goes because it is the tractable part.
See also
- Little's LawLittle's Law states that the average number of items in a stable system equals the average arrival rate times the average time each item spends there: L = λW.
- Tail LatencyTail latency is the response time of the slowest requests — typically p99 and beyond.
- ShardingSharding splits a dataset across independent database instances by a partition key, so each shard holds a disjoint subset.