How YugabyteDB Scales Temenos’ Cloud Platform to 100K Business Transactions Per Second

David Walker

Last week, Temenos made a major announcement – the Temenos Banking Cloud is achieving 100,000 transactions per second and running on a greener and more scalable platform.

Specifically, this has been a three-month project with multiple vendors, and YugabyteDB has had a significant role in the project’s success.

So, what does their benchmark of 100 million customers and 200 million deposit accounts with 100,000 transactions per second and 61 transactions per second per core mean for the database and business users?

Temenos calls out the figure of 100,000 transactions per second, but they mean 100,000 business transactions per second. These are meaningful operations for bank customers.

Understanding Temenos’ underlying technology

What about the underlying technology? Lambda functions and Kubernetes pods are running in Amazon AWS and three different databases serving the data.

But why three?

To answer that, you just need to watch John Schlesinger, Chief Architect of Temenos, talk at the Yugabyte 2021 DSS Conference. His presentation, Why Modern Core Banking needs Three Databases, not One – DSS21 – is enlightening.

In essence, it all comes down to meeting the functional requirements.

  • The first is a distributed transactional database – that is the workhorse of what John describes as the bank’s Manufacturing element.
  • The second, the Distribution element, is a lightweight, eventually consistent database for simple queries like ‘get balance’ from a mobile app.
  • Finally, the last component is the Session cache, used to record which users are connected, etc.

Temenos’ highwater benchmark utilizes three different databases – YugabyteDB for the manufacturing element, MongoDB for the distribution, and Redis for the session management.

Each database in this environment has a different role.

The session Management Database (Redis) is only used to validate whether a user is logged in and has relatively few queries.

The Distribution Database (MongoDB) does 75,000 business transactions per second. That equated to roughly 75,000 database transactions per second, a great result for MongoDB and, given they were the incumbent, an expected one.

The Manufacturing Database (YugabyteDB), with an absolute requirement for transactional consistency, is a different matter altogether (after all, nobody wants their bank account to be eventually consistent).

Establishing highwater benchmarks

Temenos chose YugabyteDB because bank transactions are both transactional and complex. Inherently, each business transaction needs many database operations.

The transactions used in the highwater benchmark were:

  • Reservation
    A reservation is what happens when you make a card payment. The card processor asks Temenos to reserve funds. This lowers the available balance. If the payment does not go through, the reservation releases. If it does, the position is updated.
    Activity: Each reservation is 9 database reads, and 2 database writes; 8,750 reservations per second
  • Booking
    A booking is a posting for one account, such as an accrual, cash deposit, or charging interest and fees.
    Activity: Each booking is 13 database reads, and 2 database writes; 12,760 bookings per second
  • Payment
    A payment is a credit transfer. This is usually made up of five transactions: reserve funds; send credit transfer; receive credit transfer response; update positions, and report done.
    Activity: Each payment is 25 database reads, and 9 database writes; 465 payments per second
  • Transfer
    A transfer is a movement of money from one account to another.
    Activity: Each transfer is 29 database reads, and 8 database writes; 1,485 transfers per second

It is important to note that each of these complex transactions requires the database to do much more work than a simple balance enquiry.

Breaking down the data

In fact, if you break down the data, you get the following:

YugabyteDB Temenos transaction benchmarks.

So, whilst Mongo did 100,000 database read/writes in an eventually consistent mode, YugabyteDB was able to exceed 430,000 database read/writes in an OLTP mode. A staggering result by any standards.

You may also wonder why Temenos did not use YugabyteDB for both functions?

Well, Temenos originally selected MongoDB for the query functions some time ago. The challenge for this year’s highwater benchmark was not just scalable high availability (which MongoDB delivers for them in the distribution part), but also transactional consistency.

That is what Temenos asked Yugabyte for, and what they know (after extremely demanding testing), we deliver.

Most importantly for Temenos, they have found the right combination of technologies to deliver stellar performance and value to their customers.

Want to know more? Read our new white paper to discover why YugabyteDB is the ideal database choice for banking and financial services providers. 

David Walker

Related Posts

Explore Distributed SQL and YugabyteDB in Depth

Discover the future of data management.
Learn at Yugabyte University
Get Started
Browse Yugabyte Docs
Explore docs
PostgreSQL For Cloud Native World
Read for Free