Transactional behavior is a standard requirement for business applications. The microservices paradigm dictates that monolithic business applications should be broken into a collection of independently deployable services which come together to deliver the business functionality. This poses a new set of interesting challenges for microservice architects a developers. One of these challenges include managing transactions across microservices. In the monolithic app, all components and libraries execute within the same process so managing transactional behavior is less of a challenge. However, in the microservices world, the transaction context has to flow through across the network from service to service whenever transactional behavior is desired. In this session, we will look at an approach developed by WSO2 to address this challenge of transaction management for microservices.

1. Managing Transactions in your
Microservices Architecture
Technical Lead, WSO2
Anupama Pathirage

2. A Simple Example
Debit £1000
from Jack’s
account
Start Start
Success Success
Success Failed
Transaction
Boundary
Debit £1000
from Jack’s
account
Credit £1000
to Tom’s
account
Credit £1000
to Tom’s
account
Transaction
Complete
We are in
Trouble
Jack’s
account
Tom’s
account
Transfer of £1000
$ $

3. COMMITTED
PARTIALLY
COMMITTEDACTIVE
What is a Transaction?
“A transaction is an atomic unit of work that is either
completed in its entirety or not done at all.”
-Fundamentals of Database Systems, Ramez Elmasri.
Begin
Transaction
End
Transaction Commit
Abort
Abort
ABORTED
TERMINATED
FAILED

4. What is a Distributed Transaction?
ORACLE
M
MySQL
M
Oracle DB
Instance
MySQL DB
Instance
Queue
Remove Message
Insert Record
Insert Record
Resource ManagersGlobal Transaction

5. Monolithic vs Microservice Architecture
Multiple modules in the same process Modules running in different processes
Monolithic Microservice

6. Transactions: Monolithic vs Microservices
C3
C1
C2
Tx
Tx
C1
C2
C3
Tx Tx
Monolithic Microservices
µ1
µ2
µ3

7. Transactions in Microservices
µ3
µ1 µ6
µ2 µ4
µ5
Joint outcome
based on either:
Orchestrator
Coordinator
Microservices Calling Each Other

8. Joint Outcome
Based on
Orchestrator

9. Joint Outcome Based on an Orchestrator
Conflicts with the “Smart endpoints, Dumb pipes” philosophy
F
E
C
B
A
D
Orchestrator
µ1 µ5µ3 µ4 µ6µ2

10. Joint Outcome
Based on
Coordination

11. Sphere of Control
µ3
µ1 µ6
µ2 µ4
µ5
Initiator
Participants
Tying together microservices as a unit
S1
S2
S3

12. Infection
µ3
µ1
µ6
µ2 µ4
µ5
Coordinator
(1)Start
(2)Context
(4) Register
(3) Request & Context
Mechanism used to extend the sphere of control
(5) Request &
Context
(6) Register

13. Agreement Protocols & Coordination Types
● Joint outcome is negotiated at the end of interactions.
● Negotiation rules and how to determine outcome is referred
to as an agreement protocol. It specifies
○ Information exchanged between coordinator and participants
○ Order of exchange
● Collection of agreement protocols is called a coordination
type.

14. Enabling an Agreement Protocol
Coordinator’s
Protocol
Endpoint
Coordinator’s
Registration
Endpoint
µ’s
Protocol
Endpoint
µ
…
Register-at
Coordination-type
...
(1) Context
(2) Register(Protocol, )
(3) Response( )

15. Coordination Types

16. Coordination Types
● 2 Phase Commit (2PC)
● Compensation

17. 2PC Coordination - Completion Protocol
Used by participants that control the end of a transaction by an explicit commit or abort command.
alt
Initiator Coordinator
Create-Context()
Micro-Transaction-Context
Commit()
Committed | Aborted | Mixed
Abort()
Aborted | Mixed

18. 2PC Coordination - Durable Protocol
success
Coordinator Participant
Prepare()
Prepared | Read-Only | Aborted | Committed
notify(...Commit...)
Committed
notify(...Abort...)
Aborted
Used by participants that manipulate persistent resources. e.g. database
Triggered by commit:
Prepare Phase
Commit Phase

19. 2PC Coordination - Durable Protocol (cont..)
Triggered by abort:
Coordinator Participant
notify(...Abort...)
Aborted

20. 2PC Coordination - Volatile Protocol
● Used by participants that manipulates volatile data sources
such as cache.
● Phase 1 (Prepare phase) has sub-phases
1) Prepare all volatile participants
- To give them a chance to persist volatile data.
- This can cause more durable participant registrations.
2) Prepare all durable participants
● Otherwise it is identical to the durable protocol.

21. ● This is used when 2PC Coordination cannot be applied.
○ In long-running interactions between microservices
○ When non-recoverable resources like files are manipulated
● In case of failure, recovery of a unit of work has to be done
by separate compensation actions.
Compensation Coordination

22. Commands
&
Data Structures

23. Create a New Context
Micro-Transaction-Context:
Micro-Transaction-Context-Version: <version number>
Micro-Transaction-Identifier: <globally unique identifier>
Name-of-Coordination-Type: <2PC | Compensation | ...>
Register-At: <registration uri of the coordinator>
create-context(in: Name-of-Coordination-Type,
out: Micro-Transaction-Context?,
fault: Invalid-Coordination-Type? )
Command:
Data Structure:

24. Register With Coordinator
register(in: Micro-Transaction-Registration,
out: Micro-Transaction-Coordination?,
fault: ( Invalid-Protocol |
Already-Registered |
Cannot-Register |
Micro-Transaction-Unknown )?
)
Micro-Transaction-Registration:
Micro-Transaction-Identifier: <globally unique identifier>
Protocol: <( Completion | Durable | Volatile | ... )+ >
Participant-Protocol-At: <uri>+
Micro-Transaction-Coordination:
Micro-Transaction-Identifier: <unique identifier>
Coordinator-Protocol-At: <uri>+
Command:
Data Structures:

25. Commit - By Initiator
commit(in : Micro-Transaction-Identifier,
out : ( Committed | Aborted | Mixed )?,
fault: ( Micro-Transaction-Unknown | Hazard-Outcome )?
)
● To end a micro-transaction successfully by committing all modifications of all
participants. As a result, the coordinator will initiate a prepare().

26. Abort - By Initiator
abort(in : Micro-Transaction-Identifier,
out : ( Aborted | Mixed )?,
fault: ( Micro-Transaction-Unknown | Hazard-Outcome )?
)
● To undo a micro-transaction, by aborting all modifications of all participants.
As a result, the coordinator will initiate a notify(…Abort…)

27. Prepare Participants - By Coordinator
prepare(in: Micro-Transaction-Identifier,
out: ( Prepared |
Read-Only |
Aborted |
Committed )?
fault: ( Micro-Transaction-Unknown |
Prepare-Failed )? )
● To request a participant to prepare for a commit.

28. Notify Participants - By Coordinator
notify(in: Micro-Transaction-Identifier,
in: ( Commit | Abort )
out: ( Committed | Aborted )?
fault: ( Not-Prepared | Micro-Transaction-Unknown | Failed-EOT )?
)
● To inform a participant of the joint outcome of the corresponding transaction.

29. Ballerina
Implementation

30. service<http:Service> travelService bind listener { //This is initiator service.
reserve(endpoint caller, http:Request req) {
// This is how you initiate a transaction
transaction with retries = 2 {
// Calling a remote participant
http:Response res = check participant->get("/hotelService/reserve");
} onretry {
// Code here will execute before retrying
} committed {
// Code here will execute after the initiated transaction has committed
} aborted {
// Code here will execute after the initiated transaction has aborted
}
}
}
Ballerina Example
Initiator

31. service<http:Service> hotelService bind listener {
@transactions:participant {
oncommit = onTxnCommit,
onabort = onTxnAbort
}
reserve(endpoint caller, http:Request req) {
// Transactional code goes here. If there are transaction
// aware stuff such as SQL connectors etc. they will
// be registered as resources affected by this transaction
// This local function call on the remote participant will
// result in the function registering with the initiator
// as a remote participant
reserveAndUpdateDB();
}
}
Ballerina Example (cont..)
Participant

32. Transactions Sidecar
Bridging to existing runtime transactions
DB
Airline Service
Ballerina Bridge
Hotel Service
TravelMgt Service
Global Transaction

33. THANK YOU
wso2.com