WePay at Openworld 2019 0912 final - MySQL
Transcript of WePay at Openworld 2019 0912 final - MySQL
10 YEARS AGO
2008: Founded in Boston starting in the P2P space
2010: Released an API
2011: Doubled down on APIs within an improved v1 and pioneered using OAuth2 for merchant authentication and on-boarding
2012: Moved from P2P to embedding payments in 3rd
party software platforms
2013: Introduced an intelligent risk engine
2014: Released first
white label API; launched
Canada support
2016: Introduced pre-certified mobile credit card readers to support in-person payment use cases; launched UK support
2017: acquired by JPMC
2018 + beyond: Announced Silicon Valley Campus; new product offeringsAbout
WePay
WePay’s Suite of Integrated Payments SolutionsOur three product offerings provide a comprehensive solution to compliment your needs, and evolve with your business as you grow
Core
A solution for software platforms who want to become payment
facilitators to integrate directly to JPMorgan Chase wholesale payments for end-to-end payments processing,
payouts, and cash management
Clear
The fully white-label solution for software platforms that want to offer integrated payments under
their own brand, while WePay handles the back-office operations
(including risk and compliance)
Link
A simple way for software platforms to enable users to accept payment
through a Chase Integrated Payments merchant account
Solutions with an unmatched advantageOur solutions offer a unique advantage through JPMorgan’s full suite of products and expertise
Brand
Enjoy the confidence that comes with offering services through one
of the world’s largest, most admired financial institutions
Scale
Partner with a processor handling over $1.4T in annual payments*, combined with investment, commercial banking,
and treasury services.
Distribution
Access the revenue generation, and user growth opportunities present through our
network of 10,000 bankers and 4MM SMBs*
*JPMorgan Chase & Co, Annual Report, 2018
● It is a Monolith, so Everything was stored there-- even our application logs!● As a payments company, being up and available is critically important to our
customers● It moves fast: 250K calls / minute with a 90/10 read write split● And it is huge!● We have put a huge investment in making MySQL highly available
In the Beginning, there was a Monolith MySQL Database
Single InstanceMySQL 5.1
3 Node MySQL 5.5 Galera Cluster
4 Node MySQL 5.5 MHA Failover Cluster
● MySQL 5.7● Semisync
Replication● GTID● Orchestrator
to handle Unplanned Events
Evolution of the Monolith MySQL DB
5 Node MySQL 5.5 MHA Failover Cluster
● We removed the fraud system from our Monolith DB as the function was provided by a set of our Microservice Infrastructure
● Microservices use MySQL, but also Redis, Cassandra, Kafka.● We have about 150 microservices and about 30 of them use MySQL● Microservice MySQL is currently Single instance / Single DB / Single service
○ This is changing soon to Single instance / many DB / many services○ We’ll keep the Single DB / Single Service relationship○ Each Instance will use the same failover architecture as the Monolith
MySQL DB
MicroServices at WePay
● 1 + 3 Master / Slave with Instances distributed across Availability Zones● SemiSync replication with GTID● Master / Slave Role transitions within seconds-- we can do them during the day● Immutable Images built by our CI/CD pipeline● HaProxy as the LB for Monolith● Evaluating ProxySQL as the LB for Microservices● Planning to upgrade to MySQL 8 Enterprise● Working with MySQL’s Engineering Team for guidance
WePay MicroService Architecture