At a glance
This top-five US. bank provides a full array of banking, investment, and insurance products and services to individuals, businesses, and institutional clients.
Their tier-one bill payment app struggled with availability, scalability, and operational challenges, partly due to limitations in their existing Oracle database architecture.
The bank adopted YugabyteDB to capitalize on the built-in resiliency and scalability of a distributed database, as well as the flexibility of a multi-region deployment.
Top 5 US Bank Updates Business-Critical Bill Pay Application
This data-driven US bank is at the forefront of consumer and commercial banking, mortgage and home equity lending, credit cards, investment banking, and wealth management. They play a pivotal role in the daily financial lives of millions of customers.
The bank, which manages thousands of apps on various monolithic databases, is currently engaged in a multi-year, high-priority modernization initiative. A key aspect of this initiative is adopting and deploying new database technologies to improve existing services and enable future offerings.
They began their modernization efforts with a critical tier 1 application, used by customers worldwide to automate and simplify bill payments. This app allows them to securely and confidently pay almost anyone or any company in the US.
At the heart of this business-critical application is the global cache, which serves reference data to the app such as biller details, addresses, and other core shared metadata. However, the cache faced several challenges stemming from the limitations of the traditional database it relied on.
Before adopting YugabyteDB, the bank utilized an Oracle database. With the app’s growth in usage and capabilities, they faced issues that the existing Oracle system had difficulty managing.
- Application Downtime: Routine tasks like patching, business continuity planning (BCP), and upgrades resulted in about two hours of weekly downtime, rendering key application components unavailable.
- Slow Performance: The global cache application struggled with high latency issues while accessing remote Oracle databases.
- Limited Resilience Options: The Oracle database failed to provide sufficient resiliency or consistency, leading to frequent system of record downtimes and the need for regular, ongoing data reloads.
- Limited Deployment Topologies: The workload, distributed across two data centers with Oracle DataGuard, required application restarts during database outages. The bank needed a three-data-center topology, which Oracle could not support.
Key Database Requirements
When evaluating alternatives to Oracle, the bank pinpointed several crucial database requirements.
- High Performance: Performance equal or better than Oracle (<25 ms on reads and <5 mins for bulk load write jobs).
- Zero Downtime: Automation of day-two critical operations to keep the app operating during planned and unplanned data center outages, node patching, and rolling upgrades.
- High Availability and Resilience: Support for multi-region deployments with the flexibility to run two- and three-data center configurations.
- Rapid Startup: Global cache app startup times must be less than five minutes.
- PostgreSQL Compatibility: Runtime PostgreSQL compatibility to simplify app and data migration, including support for advanced features like stored procedures and triggers.
“There were two pain points that drove the need for distributed SQL—resiliency and scalability. We needed a resilient, active-active solution that would support a relational data model and ACID-compliant transactions along with near linear horizontal scalability.”
— Senior Engineer of Database Strategy
Multi-region data centers supported
Drop in performance compared to Oracle
Achieved lower application read latency by utilizing local nodes in a follower-read, multi-region setup.
Simplified and automated cross-data center traffic by routing users to their nearest data center using YugabyteDB Smart Drivers.