Making Fintech More Resilient With Multi-Region Stretch Clusters

A fintech company is transforming financial technology with its new banking and card platform. Its scalable, secure, cloud-native API helps businesses quickly adjust to market shifts, processing billions of transactions annually.

Their banking and card platform is tailored to meet customers’ needs and is supported by a cloud-native infrastructure that has achieved a 99.99% uptime rate due to Amazon Web Services. It features a broad API library for easy integration and customization.

The platform offers core banking services that are suitable for modern and legacy banking systems, enhancing digital experiences and product offerings. They help customers innovate by transitioning away from the constraints of traditional banking technology.

Technical Requirements for Highly Resilient Fintech App

• Deployment: Multi-region deployment
• Public Cloud Used: Amazon Web Services (AWS)
• Cluster Size: Three nodes with one 32vCPU per region.
• Primary Database Requirement: The fintech company needed a modern database they could easily and quickly test, focusing on resilience. They completed a proof of concept with YugabyteDB Aeon for their application that facilitates transaction registrations for balance management purposes. The application operated on AWS Aurora MySQL, but Aurora did not meet their resiliency requirements. They needed to enhance the resiliency of this mission-critical application through a multi-region deployment.
• Workload Characterization: Multiple performance tests were conducted with a mix of write and read operations (75% write / 25% read, 50% write / 50% read, 25% write / 75% read).
• Replication Factor: 3
• Additional Database Requirements:
  • No Cloud Lock-in: They wanted a database that would help them avoid cloud vendor lock-in.
  • Preferred Region Setting: Capability to set a preferred region to optimize performance.
  • Public Load Balancer: Enabled via a support request to allow external tool connections.
  • Gflags Configuration: Customizable settings, notably the ‘ysql_enable_packed_row’ flag, for enhanced performance.
  • API Access: Using YugabyteDB Aeon’s REST API for operational flexibility, including node stop/start during resiliency testing.

Challenges with AWS Aurora and Other Existing Databases

The financial application, running on AWS Aurora MySQL, does not meet resiliency requirements. This key requirement motivated the fintech to migrate their existing solution (built on AWS Aurora MySQL, MongoDB, and Amazon DynamoDB) to a modern database. They needed extreme resiliency in a multi-region setting without cloud vendor lock-in.

The team decided to pursue a proof of concept (POC) on YugabyteDB Aeon (formerly YugabyteDB Managed), a DBaaS offering that allowed for a rapid setup experience. In just 90 minutes, the team created a YugabyteDB Aeon account, configured Virtual Private Clouds (VPCs), and set up three regional clusters, with one designated as the preferred region. Additionally, connectivity with their application was successfully verified.

In nearly all tests, YugabyteDB Aeon outperformed another distributed SQL database being evaluated by a factor of 3 to 5 times.

Building a Highly Resilient Multi-Region Fintech Application

Based on their requirements, the architecture for the application was designed as a multi-region deployment on YugabyteDB Aeon.

Let’s explore the key elements of their proposed architecture:

1. Multi-Region Stretch Cluster Deployment

   The application’s architecture uses a multi-region stretch cluster as a core part of their architecture, where a single cluster spans multiple geographic regions. This will help optimize data availability, performance, and compliance across different locations. By distributing the database nodes across several regions, the architecture ensures that data is replicated and accessible from various points globally.

   There are many benefits to this deployment model, including:

   • Compliance with Data Residency Requirements: Adhering to data residency laws— like GDPR—is crucial. A multi-region stretch cluster complies with these requirements by storing data locally in each region.
   • High Availability and Disaster Recovery: These clusters offer superior resilience against region-specific failures because data is distributed across multiple regions. This design is vital for mission-critical applications where downtime directly (and negatively) impacts reputation and revenue.
   • Performance Optimization: Locating data closer to users reduces latency and ensures faster access. This is especially true for the fintech application, where quick data retrieval is essential for a great user experience.
   • Extreme Scalability: The deployment can handle varying loads efficiently. If a particular region experiences increased demand, resources in that region can be scaled up independently without affecting global operations.
   • Data Localization and User Experience: Geo-partitioning within a stretch cluster ensures data is stored and managed in the region it originates from, enhancing user trust and experience.
   • Cross-Region Queries and Management: A single stretch cluster enables cross-region queries and simplifies management by eliminating the need for multiple independent clusters in different locations.
   • Cost-Effectiveness and Simplified Operations: Managing a single stretch cluster, despite its geographic spread, can be more cost-effective and less complex than maintaining multiple independent clusters.

2. Avoiding Cloud Vendor Lock-In

   Another high priority for the fintech company was avoiding cloud vendor lock-in by selecting a flexible database that would provide them freedom in their cloud infrastructure choices. As a cloud-agnostic database, YugabyteDB Aeon met this requirement. The team noted the following benefits that stemmed from choosing a flexible database like YugabyteDB:

   • Multi-Cloud Capabilities: With the ability to deploy in 66+ regions across various cloud platforms like AWS, GCP, and Azure, YugabyteDB Aeon has a broad geographic reach. This wide coverage helps customers avoid cloud vendor lock-in by allowing them to switch or distribute workloads across clouds without single-provider restrictions.
   • Simplified Management and Operational Model: By abstracting away the complexities of the underlying cloud infrastructure, YugabyteDB Aeon offers a straightforward and cloud-agnostic operational model. This allows the database to be easily managed across different cloud environments, further reducing (again) the risk of cloud vendor lock-in.
   • Future-Proofing and Scalability: YugabyteDB Aeon scales with a company’s growth, freeing it from the restrictions of a single cloud provider for its database infrastructure.
   • Reduced Costs and Complexity: There’s no need for costly migrations or re-architectures if you decide to change your cloud strategy. You can choose the most cost-effective provider.

3. Preferred Regions

   The fintech will use “preferred regions” as part of its multi-region architecture, meaning that a specific geographic region will be designated to handle most of the read and write requests. Here’s why they chose to do this:

   • Reduced Latency: By designating the region closest to the majority of the users or application servers as the preferred region, network latency is significantly reduced. If requests have fewer network hops to travel, response times are faster.
   • Improved Performance: Setting a preferred region optimizes performance by routing traffic efficiently. This is beneficial when the application demands high-speed data access and processing.
   • Balanced Load Distribution: When no preferred region is set, YugabyteDB Aeon distributes requests evenly across all regions. This ensures balanced loads, preventing any single region from becoming a bottleneck. Setting a preferred region can optimize the load distribution based on user geography and application demands.
   • Fault Tolerance: With or without a preferred region, data replication across all regions in the cluster ensures fault tolerance at the regional level. Even if the preferred region experiences an outage, other regions can still serve the data, maintaining the application’s availability.
   • Flexibility in Read-Write Operations: In architectures with read replicas, the replica serves clients’ read requests, while the preferred region manages write operations to maintain consistent performance for write-heavy tasks.
   • Dynamic Configuration: Setting or changing the preferred region post-cluster creation provides flexibility, allowing adjustments in response to evolving user demographics or app infrastructure without major architectural changes

In Summary…

This fintech chose YugabyteDB Aeon to leverage its multi-region stretch cluster for extreme scalability and resiliency and to avoid cloud vendor lock-in. Designating preferred regions enhances performance with reduced latency, while public load balancers, GFlags configuration, and API access provide extra control and flexibility. YugabyteDB Aeon was chosen over competitors due to its superior resilience and performance capabilities.

Learn more about YugabyteDB Aeon and the features highlighted in this case study through the following resources:

• Attend a Thursday demo to see geo-partitioning in action
• Sign up for a full-featured, free trial of YugabyteDB Aeon to give geo-partitioning a try
• Visit our Docs and Blog space to discover how you can build a global application with YugabyteDB