WePay + MySQLRich SteenburgSenior Director of Engineering, WePay

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

Monolith Database Single Instance Growth

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

What happened here?

● 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

Thank you!If you have any questions, feel free to send me a note:

richs@wepay.com