I was mid-session in Claude Code when everything died. Not just my session: claude.ai, the API, the whole consumer fleet, red across the board. One row on the status page stayed green and smug: Claude for Government.
Instead of getting angry, I got nostalgic. I had a front-row seat for Shopify’s version of this era: one big database, every merchant in the same blast radius, and a years-long climb into a sharded pod architecture where failures degrade (mostly) silently instead of taking the whole platform down. So when I see an isolated copy of Anthropic sailing through an outage untouched, a lightbulb turns on overhead. This is solvable, and the machinery already exists. Split the consumer fleet into a hundred isolated copies of the stack, put me on shard 42, and today’s outage becomes somebody else’s problem. Better yet: nobody’s, mostly, silently.
What the status page admits
Let me be upfront: I have no inside knowledge of Anthropic’s architecture. No diagrams, no sources, no leaked postmortems. But failure patterns tell stories, and the status page is surprisingly chatty if you sit with it.
Over the last 90 days, claude.ai has 99.35% uptime. Claude Code, 99.38%. The API, 99.46%. Claude for Government: 100.0%.
One of these numbers is not like the others.
The most recent big outage makes the story sharper. It opened as an authentication failure. Claude.ai, Claude Code, and Cowork all fell over within minutes of each other, while the API and the Console stayed up. So everything that requires a login died, and everything running on an API key kept humming. No GPU failure looks like that, and no model bug does either. The suspect list narrows to a shared identity layer, a session store, some piece of glue that every consumer product phones home to before doing anything useful.
And back in June, the press counted ten disruptions in twelve days, with the status page blaming “unexpected capacity constraints.” Different failures, same shape: when it breaks, it breaks for everyone at once.
The usual suspects
From the outside, there are a few likely culprits, and I’ll admit up front there are probably failure modes I’m ignorant of. But the ones that fit the pattern:
The application glue went offline. Shared authentication, a gateway tier, a primary database that everything reads on the hot path. When one dependency sits in front of every product, its bad day is everyone’s bad day.
Hardware and network failures. Anthropic serves models across multiple platforms and clouds. Their own postmortem from September 2025 described three separate serving bugs across three separate hardware stacks. More platforms means more surface area for weirdness.
Plain old capacity. Hypergrowth means the demand curve keeps outrunning the supply curve, and the failure mode of “not enough” looks a lot like “broken.”
Notice what these have in common: none of them are new problems. Bulkheading, circuit breakers, and sharding all exist for exactly this. They all seek to isolate customers from the slings and arrows of outrageous servers. We have battle-tested solutions with decades of production mileage, entire books about them, conference talks by the hundreds.
And to be fair to the people inside: perhaps this is a result of attempts to scale, not a lack of execution. Nobody ships a shared single point of failure on purpose. You ship a sensible architecture for the company you are, and then the company triples, and triples again, and the sensible architecture becomes the thing on fire.
Shopify solved this in 2015
Shopify hit this wall a decade ago, and usefully for the rest of us, wrote it all down.
Early Shopify was one big database. By 2015 there was no bigger server left to buy, so they sharded. That fixed the scaling problem and created a resilience problem: a sick shard still degraded the whole platform, because plenty of shared services sat in front of all the shards.
So they went further. A pod is a full, self-contained copy of Shopify serving a slice of shops: its own datastores, its own workers, its own everything that matters. The design rule is the interesting part: no action is allowed to reach across pods. Cross-pod communication isn’t discouraged, it’s impossible by design. The blast radius of any failure is one pod, full stop.
The philosophy went deeper than the database layer. Shopify built a culture around assuming hardware and networks are flaky, to the point of open-sourcing Toxiproxy, a tool whose entire job is injecting simulated network failures into your test suite so you find out how your code behaves when the flakiness arrives on a Tuesday in production.
The result, per their own engineering blog: over a hundred pods, and no major outage affecting all of Shopify since the move. Merchants stopped experiencing each other’s disasters. Failures went from front-page news to a bad afternoon for a fraction of the fleet.
The Anthropic fleet
So what would this look like for Anthropic? Cells.
Shard the customer base into fleets. Each fleet is a self-contained copy of the stack: its own auth, its own gateway, its own rate-limiting state, its own database, its own slice of inference capacity. On top, a routing layer thin enough to be boring, because the router is the one thing you can’t shard and boring is the only acceptable personality for it.
The beautiful part is that Anthropic has already built fleet number one. It’s called Claude for Government. FedRAMP compliance forces isolation: separate environment, separate access paths, separate everything. And that forced isolation is precisely what’s been sailing through consumer outages at 100.0% uptime. Government-grade isolation turns out to just be grade isolation.
(The deflating alternative explanation: maybe it’s green because nobody’s using it. Fine. But an idle cell surviving an outage still tells you the outage lived in the shared layer, not the models.)
The one real objection is compute. GPUs are scarce, and carving capacity into cells makes bin-packing harder. But Shopify’s pods share load balancers and workers where it’s safe; the isolation that matters is the stateful stuff. Anthropic could share raw accelerator pools at the scheduler level while giving every cell its own control plane. The models can be communal. The login system should not be.
And if you’re going to do it, size the strategy for the growth that’s coming. Not the next 10x or 100x. Plan the mechanism that survives 10,000x, because at the current trajectory the next architecture rewrite will otherwise arrive before the paint dries on this one.
Nobody’s the villain here
I want to be clear about the spirit of all this. Every platform company that survives its own success goes through this chapter. Shopify did. Amazon did. The engineers inside Anthropic are living through weeks I do not envy, and the fix I’m describing is a multi-year grind, not a sprint ticket.
But the status page during an outage is the clearest architecture diagram a company publishes, and Anthropic’s is telling us the consumer fleet shares too many organs. The isolated copy already exists. The prior art is public. The books are written.
I’m on Anthropic-Claude-0, and I want to be on -101. Or any duplicate, really.
Shameless plug: at Victoria Garland we spend a lot of time thinking about blast radius for Shopify Plus merchants, usually one app audit at a time. Smaller stakes, same philosophy.