Slide 1
Slide 1 text
Why Are We Trying to Turn Payment
Processing Into a Microservice?
Yuichiro Saito
Software Engineer (Backend)
Slide 2
Slide 2 text
Why Are We Trying to Turn Payment
Processing Into a Microservice?
Slide 3
Slide 3 text
Distribution
Migration
Understanding
the current
situation
Slide 4
Slide 4 text
Payment
Service
Growth
Loose
Coupling
Maintainability
Slide 5
Slide 5 text
Software Engineer
Backend
Yuichiro Saito
Slide 6
Slide 6 text
Why we’re taking the leap to
Microservices
Slide 7
Slide 7 text
Mercari is like an old hot spring inn, built floor upon floor.
=
Slide 8
Slide 8 text
Specifically, with regard to payment processes...
● Existing payment processes aren’t scalable
● New electronic payments need to be added
● Only a limited number of people understand the
payment processes
This could hinder our growth.
Slide 9
Slide 9 text
Let’s take a closer look at
this convoluted switch statement
of a workflow...
Slide 10
Slide 10 text
First...
Take a look at the way payment methods are being
added (in pseudocode).
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
SAY WHAT?
Slide 16
Slide 16 text
Problems
● The current structure of
payment processes is
not scalable.
● It’s become necessary to
develop loose coupling
between the electronic
payment services in
development.
Solutions
● Migrate to microservices
using the grpc interface
● Reimplement payment
processing
(PaymentService)
● At the same time,
move toward a sparse
organizational structure
Slide 17
Slide 17 text
Refactoring
Microservices
Solutions
Options!
etc.
Slide 18
Slide 18 text
Results Achieved
● Better maintainability
● Ability to separate responsbilities
● Easier to add new payment methods
● Increased number of people who understand
payment processing through reimplementation
Slide 19
Slide 19 text
The battle with potentials errors of
distributed transactions
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
But it’s still too early to celebrate!
Let’s take another look at the current payment
processing.
Slide 22
Slide 22 text
If the transaction fails,
we just call the
rollback function.
Slide 23
Slide 23 text
After payments migrate to microservices...
Payment processing becomes a distributed transaction.
Slide 24
Slide 24 text
Problem 1:
Processed results exist independently in each system.
Slide 25
Slide 25 text
payment->consume()
is executed as an
independent process.
If point payment and
card payment occur
simultaneously and one
of them fail, the result
will be incorrect.
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
Solution 1: Separate
1. Authorize payment method.
2. Continue the purchase process
in a state where payment abilities
are guaranteed.
3. If no errors, finalize payment.
4. If there are errors, release
authorization of payment method.
Idempotency of the process is
guaranteed.
Slide 28
Slide 28 text
Problem 2:
What happens when a partial failure occurs within
PaymentService?
Slide 29
Slide 29 text
This process can’t
begin.
When
payment->consume()
is slow...
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
Characteristics
● Asynchronous processing is
possible.
● Automatic re-queuing and retry
upon failure. High availability.
● Can revert the state of
unrecoverable failures.
The successive addition of new
payment methods also becomes
possible.
compensating
transaction
Solution 2: State Machine
retry retry
success
point
consump-
tion
card
payment
succ-
ess
start
fail
Slide 32
Slide 32 text
How to reduce the influence on
accounting systems
Slide 33
Slide 33 text
Forgetting something?
Slide 34
Slide 34 text
1. When migrating payment
systems, logs are processed
in parallel in the current and
new systems.
2. Parallel processing ends
after the migration to
PaymentService is
complete.
Payment
Business
Payment
Service
Current
System
Done
DB
DB
Pub/
Sub
Slide 35
Slide 35 text
To conclude
Slide 36
Slide 36 text
Better maintainability
→
Slide 37
Slide 37 text
Separating responsibilities allows for easier
development and maintainability.
Separation of
responsibilities
Flexible
expansion
Eliminating
dependence
As the system scales, reorganizing the
organizational structure allows for independent
teams.
Through redesign, re-implementation and
documentation, we can ensure that each task
can be understood and completed by anyone.
Slide 38
Slide 38 text
Understand the nature of distributed transactions
during implementation of payment processing.
Ensure that there is a method to
revert to previous state.
Slide 39
Slide 39 text
Prepare for the migration
of accounting systems
using parallel processing.
Slide 40
Slide 40 text
Now in the last spurt before release!
Images from いらすとや (https://www.irasutoya.com/)
Slide 41
Slide 41 text
No content