“Because so much of our daily lives are dependent on technology, we really do not accept failure anymore as a society.” That line from Kevin Holditch, Head of Engineering at Form3, opened his RoachFest London 2026 session — and it is a fair summary of why a real-time payments platform ends up rebuilding its entire cloud architecture around a database, not just adopting one.
Why V1 Was Not Enough
Form3’s V1 architecture was solid. It let the team move fast and build real market momentum — the kind of foundation most platforms are happy to run on for years. But two forces converged on it that no amount of incremental tuning could resolve:
- Markets and customers kept growing, straining assumptions the original design never had to account for at that scale.
- Regulators grew nervous about single-cloud concentration risk. For a real-time payments platform, that is not a preference — it is a hard constraint from the Prudential Regulation Authority and the Bank of England. A payments provider whose entire operation depends on one cloud provider’s uptime is, from a regulator’s perspective, a systemic risk the industry cannot carry.
The response was a full evolution to a V2 multi-cloud architecture, with CockroachDB and Kubernetes at the core of the redesign.
Three Clouds, One Logical System
The V2 architecture that resulted is not three separate deployments that happen to share a brand name — it is one logical system deliberately spread across three independent cloud providers:
- Three independent cloud providers, architected so that a Kubernetes failure in one does not touch the others.
- Private cross-cloud networking — pods communicate across cloud boundaries with direct line-of-sight, not through the public internet.
- A single logical messaging cluster spanning all three clouds, distributing payment work evenly across them.
- A payment can start on Google Cloud and continue on a different provider mid-journey — the architecture does not pin a transaction’s lifecycle to a single cloud.
- One CockroachDB cluster across all three clouds, with quorum writes keeping every payment safe regardless of which provider is currently under strain.
- Applications migrated from Java to Go, a better fit for the cloud-native operating model V2 requires.
Form3’s own database requirements, laid out on their session slide, read like a checklist any regulated payments platform should be measuring candidates against: cloud-agnostic, quorum writes, consistent reads, fault-tolerant, zero-downtime upgrades. That is a demanding list, and it rules out most conventional relational database deployment patterns immediately — a primary/replica setup pinned to one cloud fails the cloud-agnostic requirement before the conversation even starts.
The Inflection Point
Kevin’s framing captured something bigger than Form3’s specific rebuild: CockroachDB is no longer just “worth the complexity and cost.” For a platform with these regulatory constraints, it has become the easiest and most affordable path to a resilient operational database of state — the old cost-versus-complexity tradeoff calculation has flipped.
His bolder claim extends past Form3 entirely: every company will own an agentic database of state — not a question of if, but of which kind of state layer they end up building, whether intentionally or not. The hidden risk is letting it happen by default: a sprawling legacy of state accumulated by accretion, service by service, without anyone ever designing it as a system. That risk is not unique to payments — it is the same data residency and multi-cloud challenge every regulated industry runs into once “the data has to live somewhere specific, provably, under audit” stops being a hypothetical and starts being a Friday-afternoon regulator letter.
Why This Matters Beyond FinTech
Form3’s constraints are unusually strict — few industries have a central bank explicitly dictating architecture decisions — but the underlying lesson generalizes. Any platform that cannot tolerate its cloud provider’s outage becoming its own outage eventually faces the same choice Form3 did: either design multi-cloud resilience deliberately, with a database that can hold quorum consistency across providers, or discover the gap during an incident that regulators, customers, or both will remember.
Automating Overnight Chaos Testing
The V2 architecture is not just a design on paper — Form3 stress-tests it every night. A platform leader on the team described replacing the industry-standard annual disaster-recovery test with always-on automated chaos testing, and the slide behind the point was blunt about why: a once-a-year checkbox exercise is manual, synthetic, and tests whether people can follow a runbook — not whether the platform actually survives failure. It made sense when releases shipped quarterly. It stopped being credible the moment Form3 started shipping multiple times a day.
The replacement runs continuously. Form3 built fake customers inside every cloud provider — living outside the real platform boundary — with in-house simulators that mimic every payment scheme closely enough that the platform under test cannot tell the difference from live traffic. Overnight, the chaos scenarios run real disasters against that synthetic traffic: dropping an availability zone, or taking an entire cloud provider offline. Every morning, the team checks whether any release from the day before broke a disaster scenario, rather than finding out during an actual outage. It is the same principle behind the V2 rebuild applied one level down — resilience that is verified continuously is worth more than resilience that is merely documented.
Related Reading
- RoachFest London 2026: Distributed SQL Meets AI Resilience
- Inside Cockroach Labs’ AI Playbook: The Database Reckoning
- Data Residency in Multi-Cloud Kubernetes
- Auth0 for AI Agents: DORA, C5, and GDPR Compliance
About the Author
I am Luca Berton, AI and Cloud Advisor. I work at the intersection of distributed systems, platform engineering, and enterprise AI deployments. Book a consultation.
