PayPay migrated their payment database from Amazon Aurora to TiDB in 3 months. They chose TiDB for its horizontal scalability, high availability, and ability to remove the need for application-level sharding. They performed an accuracy verification by comparing data between the old and new databases, as well as across microservices. Performance and availability testing was also conducted during the migration to validate the migration was successful. After 3 months of the new TiDB database in production, PayPay saw the expected performance improvements and zero incidents, finding TiDB to be a reliable replacement.

1. TiDB at PayPay
How we migrated in 3 months
Presented by
Munenori Hirakawa
PayPay inc.

2. PayPay is..
● No.1 share mobile payment in Japan
● 29M users / 2M merchants / 1B transactions
● Launched at Oct 2018 by Softbank,
Yahoo! JAPAN and Paytm

3. Payment
Finnet Wallet
App POS Online
Credit card
Network
Architecture of PayPay
● Offline and online payment
● Users can pay with credit card or user’s balance
● Microservice architecture on Amazon AWS
● Spring Boot + MySQL (Amazon Aurora)
● Payment became the bottleneck

4. ● MySQL compatible
● Horizontal scalability and high availability
● Free from application level sharding
● A lot of experience in production
Why we chose TiDB

5. ● Pros of Aurora
○ Read-write separation contributes to stability
○ AWS managed service
● Cons of Aurora
○ Binlog replication becomes bottleneck for latency under high TPS
(We need binlog replication for DR)
Comparison with Amazon Aurora

6. New Payment DB with TiDB
PD
TiDB
TiKV
PD
TiDB
TiKV
Pump
Drainer
Drainer Backup
binlog replication
DR site
Slave cluster
Master cluster

7. ● Clone production data
● Verify with sync-diff-inspector
Ensure accuracy:
In-domain verification
Application
in production
Aurora
p6spy
Aurora TiDB
Consumer
Compare by
sync-diff-inspector

8. Compare by Amazon
EMR (like Hadoop)
Payment
Finnet Wallet
App POS Online
Credit card
Network
Ensure accuracy:
Cross-domain verification
● Verify across microservice components
● Keep verifying after the migration

9. Ensure performance and availability
● Verified the performance by optimizing the setting and the application
○ Connection pool size, drop indices
● Tested 30+ failure scenarios and confirmed RPO and RTO
○ Instance down, Cluster down, AZ down etc..

10. ● We chose “one-shot” migration
rather “incremental”
● Set binlog in the opposite direction
for rollback
Migration steps
Aurora TiDB
Payment
Aurora TiDB
Payment
Before migration
After migration

11. Thoughts after the migration
● Expected performance
● 0 incident for first 3 months, it’s reliable
● Good support (Thanks to PingCAP)

12. ● Upgrade to 3.x or higher
● Migrate other databases
● Get more knowledge and experience,
and contribute to TiDB community!
Future roadmap

13. Thanks!