Corvin Active-Active
“We will never become dependent on the kindness of strangers. … we will always arrange our affairs so that any requirements for cash we may conceivably have will be dwarfed by our own liquidity.”
Two sites, one production. Both take traffic and share every GPU. Lose one and inference retries at once, web moves in seconds, and the database promotes itself. A third site breaks ties. This is the plan; every time on this page is a target the drills will measure.
The claim, in four numbers
Both serve production. Both run every app. One database writes; the other holds a live replica.
GPUs in the production pool, day to day. Five in a failover. A failed call retries on another card.
Target for the database to promote itself. Web moves in seconds. Up to ~1 s of the newest writes at risk.
Votes pick the primary. A witness at a third location means a cut link can't split the data in two.
Transcript
Sources and honest limits
DECKCorvin active-active architecture decision, 8 Oct 2026 (internal deck; names, hosts and tickets withheld)BRKWarren Buffett, Berkshire Hathaway letter to shareholders, 2009: https://www.berkshirehathaway.com/letters/2009ltr.pdfPGPatroni + etcd: leader key with a time-to-live; a majority of three members elects the primaryCFCloudflare Load Balancing: two pools, health checks, prefers the site holding the database primary
This is an architecture plan, written before any failover has happened. The 15–30 s promotion, the seconds-long web failover and the ~1 s of writes at risk are targets from the plan; nothing has been drilled yet. Replication is asynchronous on purpose: writes don't wait on the link between sites, and the price is that the newest fraction of a second may be missing after a promotion. Synchronous replication would remove that and make every commit pay a round trip. Requests in flight on the lost site fail and are retried. Host names, people and internal tickets are left out.
How we solved it.