Fan-Out
One incoming request causing many outgoing ones, which multiplies both load and tail latency.
Two costs, and the second is the one people miss. Load amplification: one request becoming twenty downstream calls means a downstream service sees twenty times the traffic, and a modest increase at the front becomes a large one behind. Tail amplification: if a request waits for all twenty and each has a p99 of one second, the probability that none is slow is about 0.99²⁰ ≈ 82% — so nearly one request in five is slow, from components that are individually fine.
Design responses: reduce the fan-out (batch, denormalise, precompute a read model), make it partial (return what arrived within the deadline and degrade the rest), or hedge (send a duplicate after a short delay and take the first response).
The related design-time choice is fan-out on write versus on read — precompute for every recipient when something is published, or assemble when each recipient asks. Social feeds are the canonical case, and the answer is usually both, split by how many followers an account has.