A leading Japanese FinTech company experienced rapid growth, fueled by a popular mobile payment application. The company faced significant challenges in managing its database infrastructure with a user base surpassing 65 million while processing over $67 billion in annual transactions. The core payment system, initially built on Amazon Aurora MySQL, struggled to keep pace with the escalating transaction volume and frequent traffic spikes.

The Challenge: Overcoming Performance Bottlenecks with Primary Payment Database

This FinTech company offers online and offline payment solutions and supports various payment methods. Users can scan a merchant’s QR code using its app or have their barcodes scanned at the POS. Additionally, online merchants use them for transactions. Users can pay through registered credit cards or wallet balances. Now, with payment as the core business, this company is aiming to become a comprehensive app that can be used in all aspects of daily lives.

Business scope
Figure 1. The types of payment services this Japanese FinTech company offers.

The company’s payment system was a complex ecosystem comprising 80+ microservices, primarily built on Java and Spring Boot. All payment and transaction data are handled by the primary database, Amazon Aurora MySQL. As the business grew, the payment database became a bottleneck, necessitating a move to a more scalable database.

pre architecture
Figure 2. Japanese FinTech company’s original architecture with Amazon Aurora MySQL.
Rapid increase in the number of registered users of the Japanese FinTech company.
Figure 3. Rapid increase in the number of registered users of the Japanese FinTech company.
  • Performance Demands: With the rapid increase in the number of registered users and the corresponding transaction volume, the database’s performance became a critical issue. Amazon Aurora was hard to keep pace with the rapid growth due to its architecture. 
  • Frequent Traffic Spikes: The company experienced frequent spikes in traffic due to various promotional campaigns. These promotions often led to sudden and massive increases in transaction volumes, which the existing database setup struggled to handle. The inability to efficiently manage these traffic spikes resulted in performance degradation and impacted the user experience.
  • Become Part of the Whole Ecosystem: To become part of the whole data ecosystem, replication has to be enabled to ensure recent updates to be synchronized to downstream systems, enabling binlog replication will cause remarkable performance downgrade.
  • High Availability Requests: Additional data replication requirements for disaster recovery intensified the high latency problem for commits.

The Solution: A Hybrid Database Approach with TiDB

new architecture
Figure 4. Japanese FinTech company’s updated architecture with Amazon Aurora and TiDB.
Data flow in the new hybrid database architecture
Figure 5. Data flow in the new hybrid database architecture

After migrating partially to TiDB, the company’s architecture underwent significant changes to address its previous challenges while still leveraging Amazon Aurora MySQL’s strengths. 

  • Hybrid Database Setup: The company adopted a hybrid database setup where TiDB and Amazon Aurora MySQL coexisted. This setup allowed them to utilize TiDB’s strengths to handle high traffic volumes and ensure high availability while still benefiting from Amazon Aurora’s robust features.
  • Selective Migration: The migration to TiDB was a strategic move to migrate specific components most affected by traffic spikes and performance issues. The most mission critical components (payment and wallet), which experienced the highest load and required the most reliability, were moved to TiDB.
  • Seamlessly Fit into the Ecosystem: TiDB’s replication makes it easy to fit into the existing data ecosystem without any issue
  • Improved Scalability and Availability: By leveraging TiDB for their system’s most critical and high-traffic parts, the company could better handle the frequent traffic spikes. TiDB’s horizontal scalability and strong consistency improved the system’s reliability and performance.

The Results: 30% Lower User Latency with a Higher QPS for  Single Cluster

The migration to TiDB enabled the company to optimize the performance and reliability of its most critical components while still leveraging Amazon Aurora MySQL’s strengths for other parts of its system. This hybrid approach allowed them to address specific challenges effectively and maintain a robust and scalable architecture.

  • Better Scalability: TiDB provided the horizontal scalability to handle increasing transaction volumes and traffic spikes, ensuring the company’s system could grow with its user base.
  • Enhanced Performance: The API latency on the user end is now 30% lower compared with Amazon Aurora, with a higher QPS for single cluster.
  • High Availability: TiDB’s robust failover capabilities minimized service disruptions, addressing one of the key challenges faced with Amazon Aurora. The company survived an Availability Zone level outage in the AWS Tokyo Region in 2021. TiDB automatically recovered within 18 seconds, without manual intervention.

The Future

Japanese FinTech company’s future architecture utilizing TiDB, TiCDC, and TiFlash.
Figure 6. Japanese FinTech company’s future architecture utilizing TiDB, TiCDC, and TiFlash.

As the company continues to evolve, its architectural roadmap includes critical upgrades aimed at further optimizing scalability, performance, and analytical capabilities. One of the key components in this future architecture is the replacement of TiDB Binlog (composed of Pump and Drainer) with TiCDC. This transition is necessary to improve data replication and streaming capabilities, providing real-time data processing and ensuring minimal latency in the system’s transactional operations. TiCDC will enhance the overall data synchronization between the components, making the architecture more resilient and responsive to dynamic data flows.

In addition to this, the company also plans to introduce TiFlash to replace Amazon Aurora’s OLAP functionalities, which will simplify the overall system architecture and reduce operational overhead.

This forward-looking strategy will allow the company to maintain its leadership in the FinTech space, continuously delivering high-performance services that adapt to evolving market needs.

Conclusion

This Japanese FinTech company’s successful migration to TiDB has not only resolved its critical scalability and performance issues but also set a benchmark for similar businesses grappling with rapid growth and complex transactions. By choosing TiDB, it leveraged a horizontally scalable, MySQL-compatible database solution that minimized application changes and simplified management.

For businesses experiencing similar challenges—whether it’s due to exponential user growth, high transaction volumes, or the need for reliable disaster recovery—TiDB offers a compelling solution. Its ability to provide horizontal scalability and strong consistency without complex sharding makes it an attractive choice for companies in sectors like FinTech, E-Commerce, and beyond. TiDB’s architecture ensures your database infrastructure can seamlessly keep pace as your business scales, offering robust performance and reliability.

Elevate modern apps with TiDB.

Book a Demo