Shared Library Blast Radius measures the scope of impact when a shared library or common module is modified in a monorepo. A large blast radius means that a single change can potentially break many downstream consumers, requiring extensive testing and careful rollout. Understanding blast radius helps teams make informed decisions about library boundaries, versioning strategies, and the trade-off between code sharing and coupling.
Number of services affected by a single library change. Unique to monorepo scale.
Unique to monorepo scale. A single change to a utility function can affect 10–50+ services. Google's Rosie tool (automated LSC — Large-Scale Changes) manages this by splitting changes into reviewable chunks. Without impact analysis, shared library changes are the highest-risk activity in a monorepo.
AMPLIFIED: A shared library incident while domain experts are in a different TZ means the on-call team lacks context. Blast radius × TZ gap = recovery time measured in shifts, not hours.
Shared library impact is proportional to consumer count, which grows with org size. A single utility change can affect 10-50+ services at scale.
A shared utility change affecting 50 services has 50× the blast radius of a single-service change.
Shared library changes trigger testing across all consumers. More affected projects = longer test execution.
Changes affecting many teams require reviews from many CODEOWNERS. Each reviewer adds latency.
Larger blast radius = more teams need to be aware and coordinate. Directly proportional.
A bug in widely-shared code can cause cascading failures across many services simultaneously.
Atomic changes to shared libs + all consumers create enormous PRs.