How Form3 is building unkillable payment infrastructure

How Form3 is building unkillable payment infrastructure
[ Webinar ]

Payments System Webinar

For 16 years he built payment systems at Square, BlackRock, and Varo. Watch him explain the right and wrong ways to build payments systems.

Sign up

What do you do when you need the speed of a NoSQL database and the consistency of a relational database at the same time?

That’s the challenge that confronted Form3, a UK-based company that provides financial institutions with easy access to managed payments infrastructure via an API, when they kicked off a new project.

The speed of Redis with the consistency of RDBMS

Historically, Form3 had implemented their payment gateways using primarily AWS and Postgres. But a couple of years ago, they started building a new FPS gateway that required leased lines, physical HSMs, and other hardware that meant there was no way to operate exclusively in the cloud. “We had to start spinning up physical data centers,” says Form3 Head of Architecture Sam Owens.

In fact, it was even more complex than that: the new gateway would be built with free Kubernetes clusters: one for each of the two physical data centers, and an additional one in the cloud. This ruled out Postgres – Form3 knew that for this project, they would need a truly distributed database.

They also needed something that would be fast. That’s why they initially landed on Redis, a NoSQL database that’s known for its speed.

Redis “proved to be fine for getting us going,” Owens says, “[but] we have various consistency requirements that then couldn’t be met because Redis is designed for speed rather than consistency.”

That wasn’t a sacrifice that Form3 could make. They didn’t need speed or consistency, they needed both. So they started looking for alternatives.

“We had various people on the team that had used Cockroach in previous projects at previous companies, and they were really keen to start using it,” Owens says. “So we plugged it in, benchmarked it against Redis, and to our surprise, it performed just as well for our use cases. And it also gave us those consistency guarantees that we were after.”

This gateway is now handling more than a million transactions per day, Owens says. “I think with some of the customers onboarding,” Holditch adds, “that [number] will 20-30x over the next year or so.”

Why add a Kubernetes cluster in each cloud vendor?

CockroachDB is performing so well as the backbone of the FPS gateway that Form3 is now in the process of implementing it into another project.

[ guide ]

Banking resilience at global scale with Distributed SQL

download guide →

“Regulators are saying that we are becoming critical infrastructure because of the amount of volume that we are doing,” says Form3 Head of Platform Kevin Holditch. That, in turn, has led banks to wonder about what would happen if AWS went down, considering that a lot of Form3’s current software was “was written to work on AWS, it was written against Postgres.”

Postgres itself has also been a cause of concern from time to time, Owens says. “There was an upgrade forced upon us that required downtime, which we were particularly frustrated about […] One of the aims of our platform was to be up 24/7, constantly. So having this sort of downtime that we really couldn’t work around was very frustrating for us.”

The solution? “Take what we’ve done with the FPS gateway, but do that a level up,” says Holditch. “Rather than having two data centers and one cloud, we’re going to have a Kubernetes cluster in each cloud vendor, so Azure, AWS, GCP – and run Cockroach across the three.”

“The idea of the platform is to be able to survive a cloud vendor outage,” Holditch says, “so we’re not going to be dependent on any cloud vendor.” That makes CockroachDB, with its support for multi-cloud and hybrid cloud deployments, a perfect fit.

And since CockroachDB supports the Postgres wire protocol and most Postgres syntax, moving workloads from their previous Postgres/AWS setup to a CockroachDB multi-cloud setup is more straightforward than many database migrations.

The ultimate goal, Holditch says, is to be able to tell banks that they don’t have to worry about an AWS outage, for example, because their platform will keep running even if AWS goes down. “That’s where we still want to get to, and it’s quite ambitious,” he says.

“We feel like we’re sort of pushing the boundaries of what’s possible,” says Holditch.

But technologies such as CockroachDB and Cilium “are making that easier […] than it would have been, say, a couple of years ago.”

RELATED How to use Cluster Mesh for multi-region Kubernetes pod communication

Watch the full webinar

For more information, check out the full webinar recording!

Or, learn more about how CockroachDB is helping financial service companies guarantee consistent transactions, navigate banking regulations, and scale elastically.

About the author

Charlie Custer github link linkedin link

Charlie is a former teacher, tech journalist, and filmmaker who’s now combined those three professions into writing and making videos about databases and application development (and occasionally messing with NLP and Python to create weird things in his spare time).

Keep Reading

How to build a payments system that scales to infinity (with examples)

Everybody, from SaaS applications to retailers, has to deal with payment processing. But architecting a system that can …

Read more
Brazil's Nubank uses CockroachDB for application resiliency and scale

Nubank, a leading Brazilian financial technology company valued at more than $45 billion dollars, needed a scalable SQL …

Read more
Fueling the startup economy: Crowdfunding on a transaction-oriented system

This is the story of how Australian-based Birchal created a crowdfunding platform on CockroachDB 

Early stage capital is …

Read more