Modernization

The cost of a second datacenter

Multi-site resilience is bought in step functions, not increments. On the honest arithmetic of the second location, cloud or concrete.

Code, Noted3 min readModernization

The second datacenter never costs what the first one did. It costs more, and the excess is not in the racks. It is in what the second site does to every system that must now exist twice, agree with itself over a wire, and fail over on a day nobody chose. This arithmetic is old, but each generation re-derives it, most recently in the language of cloud regions.

Engineering sheet of two identical structures joined by a dimensioned link, one drawn in dashed line

Start with what the second site is for, because the purposes have different price tags. Disaster recovery (cold or warm standby) buys survival of a site loss at the cost of hardware that mostly idles and a failover procedure that mostly decays. Active-active buys capacity and seamlessness at the cost of the hardest problems in distributed systems moving onto your payroll: split brain, replication lag, the write that must be accepted in exactly one place. The industry's scar tissue here is instructive; the distributed-consensus outages of the past decade (Roblox's 73-hour outage in 2021 being the canonical public postmortem) were second-site problems in spirit: coordination machinery failing in ways single sites cannot.

The step-function nature of the cost is the part budgets miss. One site to two is not twice the money; it is a phase change. Deployment tooling must become topology-aware. Data must choose, explicitly, per system, between synchronous safety and asynchronous speed. Observability must distinguish "site B is down" from "the link to site B is down," which are different emergencies with opposite responses. And the failover that justifies the whole budget must be rehearsed on a schedule, because an unrehearsed failover is a rumor, not a capability. Two to three, by contrast, is nearly linear; the expensive lesson was the second.

The cloud reframed this arithmetic without repealing it. Multi-region architectures buy the second site's benefits with the same step function attached, which is why so many companies run single-region with global ambitions and quiet discomfort. Meanwhile the repatriation movement, with 37signals' cloud exit as its loudest exhibit, rediscovered the other direction: their math worked partly because a stable workload on owned hardware in colocation, two sites' worth, still undercut the elastic premium they were paying to rent someone else's second site. The instinct to run one's own hardware to understand it is not nostalgia; the homelab argument makes the professional case for it at small scale. The lesson travels both ways: what you are pricing is never the racks. It is the topology.

The discipline this journal would prescribe is to make the requirement carry its own arithmetic. "We need multi-site" is not a requirement; it is a mood. The requirement is a recovery time and a recovery point, signed by someone who owns revenue, priced against the alternatives: a rehearsed restore, a degraded read-only mode, a contractual apology. Sometimes the honest answer is that four hours of annual downtime risk costs less than the standing tax of distributed consensus, and boring wins again. Sometimes the business genuinely cannot be down, and the step function is simply the price of being that business.

Either answer is respectable. The unrespectable position is the common one: a second site purchased as insurance, unrehearsed, drifting out of sync, delivering the costs of active-active with the guarantees of a hope. Insurance you cannot exercise is a donation. The second datacenter is a commitment, and like most commitments, cheaper to decline in daylight than to keep halfway.