All insights
Joint whitepaper with Yugabyte
Banking at Scale
Ultra-resilient core banking on YugabyteDB and FYNDNA's cloud-native platform
Written with Yugabyte. Payments in Tier-1 banks already run past 3,000 tps and are growing at about 25% a year, which puts the data layer, not the application, on the critical path for availability. This paper covers what FYNDNA and YugabyteDB tested together and what is running in production today.
- Length
- 23 pages
- Read time
- About 15 minutes
- Written for
- Chief architects, heads of infrastructure, and database and platform engineering.
DownloadPDF, 6.8 MB
No form, no email address required.
DownloadPDF, 6.8 MB
No form, no email address required.
Key takeaways
- 1Two live regions, two cloud providersActive-active was validated with two independent YugabyteDB deployments about 1,000km apart, replicating bidirectionally, running on GCP and AWS with integration back to on-prem systems. Putting the two regions on different providers means a provider-level outage cannot take both.
- 2Each deployment held 500 tps with 250ms replication lagConsistent application behaviour was observed at 500 tps processed by each deployment, with a replication phase lag of 250ms. Normal, failover and failback modes were all designed and validated, with a monitoring service in both regions watching the database, Kafka and the services themselves.
- 3The database was upgraded in production, with no downtimeA YugabyteDB platform version upgrade was carried out on the payments hub databases in the bank’s production cloud landing zone. Zero downtime for the component, and no technical declines encountered during the process.
- 4Node failure was tested in production, not in a labNodes in one zone were brought down while the application continued running with minimal transaction failure, and behaved the same way when the node came back with data replicated across all zones.
- 5Pricing sustained 75,000 inserts a second under 4msTested on single-table pricing workloads. Behind it, the bank’s product landscape was simplified from more than 600 priced products to 83, which took the processing SLA from seven hours to three.
- 6The customer record runs a CQRS split across three cloudseParty separates its write and read repositories so each can be tuned for its own performance profile, and operates in production across Azure, AWS and Temporal Cloud.
Talk to the architects who wrote this.
The decisions in this paper were made against live traffic at a bank that could not go down. Tell us what your constraint is and we will go through how it applies.