Is Your Shared Foundation a Single Point of Failure?

Yes, a shared foundation is a single point of failure, and no, that is not a reason to avoid it. A bug in shared auth is a bug in every app that uses shared auth. That is the real cost of sharing, and anyone selling you a foundation without admitting it is lying. But the same coupling that spreads a bug also spreads a fix, and if you engineer the failure surface deliberately, the shared foundation ends up more reliable than twenty apps each rolling their own version of the same thing badly. The answer is not less sharing. It is sharing with blast-radius discipline.

I run a whole portfolio on shared pieces. I think about this exact risk constantly, because I am the only person on call, and I have learned where the foundation is allowed to be a shared dependency and where it absolutely is not.

The coupling cuts both ways

When people say a shared foundation is a single point of failure, they are right about the failure and wrong about the conclusion. Yes, one bug can hit everything. But consider the alternative. If every app has its own hand-rolled auth, you do not have one point of failure, you have twenty, each with its own bugs, each unpatched on its own schedule, each a surprise. A security flaw in the shared auth gets fixed once and every app is safe. The same flaw copy-pasted into twenty apps gets fixed nineteen times if you are lucky and someone remembers the twentieth.

Concentrated risk is easier to manage than scattered risk. This is the same argument I make for one Postgres box under every app and one governed foundation under every company: a small number of things you watch closely beats a large number of things you forget about.

Separate the shared code from the shared runtime

Here is the distinction that defuses most of the risk. A shared library is not the same kind of single point of failure as a shared running service. A shared library is code that each app builds into itself. A bug in it is bad, but it only reaches an app when that app deploys the bad version. Apps pin versions, so a bad release does not instantly take down everyone. That is a controllable failure.

A shared running service, like one auth server every app calls in real time, is a different animal. If it goes down, everything goes down at once, immediately, with no version pinning to save you. Both are worth having, but you protect them differently. Libraries you protect with versioning and staged rollout. Live services you protect with redundancy, health checks, and the fallbacks you design before the thing fails. Conflating the two is what makes people scared of foundations that are actually quite safe.

Contain the blast radius on purpose

You reduce single-point-of-failure risk with a few deliberate choices.

• Pin versions. No app tracks the foundation's latest automatically. A bad release sits in staging, not in production, until each app chooses it. That alone converts "instant portfolio outage" into "one app caught it in staging."
• Stage rollouts. New foundation versions hit one low-stakes app first. If it breaks, it breaks there, and you learn before the important apps upgrade.
• Test the foundation harder than the apps. The shared code carries more risk, so it earns more tests. I test the shared foundation so it does not break apps with far more rigor than I test any single app, because its blast radius is larger.
• Keep the live shared services small and redundant. The fewer real-time shared dependencies, the fewer things that can take everyone down at once. Prefer shared libraries over shared services where you can.

Do these and the shared foundation stops being a fault line and becomes a chokepoint you can actually defend.

The real risk is an untested, unversioned foundation

The version of a shared foundation that genuinely is a dangerous single point of failure is the one with no version pinning, no staged rollout, and thin tests, where a careless commit ships to every app on the next deploy. That is not an argument against shared foundations. It is an argument against building one carelessly, which is one of the classic mistakes building a shared foundation.

Discipline is the difference. A well-run foundation concentrates risk into a place you watch like a hawk. A badly run one concentrates risk into a place nobody is watching. Same architecture, opposite outcome.

The honest tradeoff

I will not pretend the coupling is free. When my shared auth has a bug, I feel it everywhere, and that is a real weight to carry. But I would rather carry one thing I understand deeply than twenty things I half-remember. The shared foundation makes the risk legible, and legible risk is manageable risk.

I keep the foundation's tests, versioning, and staged rollout wired into the build platform at Bootspring, so a shared change is proven against the portfolio before any important app takes it. Yes, it is a single point of failure. Engineer it like one, and it becomes the most reliable part of your whole stack.