Most of people nowadays think microservices architecture is a great way to build any system. They visit conference talks, read books and review tutorials, where ‘hello world’ applications are built just in several minutes using microservices approach. But the reality is not so wonderful and one of the biggest pain is hidden inside distributed business transactions. In monolith application this topic is almost completely covered with DB level transactions. In distributed world you have to face many issues trying to implement reliable and consistent business logic. In this talk we will review different types of problems related to distributed business transactions, popular SAGA pattern, frameworks and techniques to simplify your life without compromising quality of the system.

1. Saga about distributed
business transactions in
microservices world
Mikalai Alimenkou
@xpinjection
https://t.me/xpinjection_channel
https://xpinjection.com

3. Telegram channel
https://t.me/xpinjection_channel

4. Disclaimer
This talk is based on
personal experience

5. Local ACID transactions universe

6. Developers love this universe
High level abstractions like Spring Data hide real SQL
requests from developer
New generation of developers doesn’t pay attention to
low level RDBMS rules
Hibernate controls queries ordering and execution
timeline
Developers believe in transactions magic, so always
feel comfortable about data consistency

7. Microservices destroyed this universe

8. Distributed transactions are everywhere

9. Real world
transactions…

10. First rule of microservices club: be
optimistic and don’t raise complex
questions!

11. Hello world samples on conferences

12. Some books tell
you truth about
microservices
complexity…

13. Saga pattern definition
https://microservices.io/patterns/data/saga.html
Implement each business transaction that spans multiple services as a
saga. A saga is a sequence of local transactions. Each local
transaction updates the database and publishes a message or event to
trigger the next local transaction in the saga. If a local transaction fails
because it violates a business rule then the saga executes a series of
compensating transactions that undo the changes that were made by
the preceding local transactions.

14. Very hot “modern” topic!
https://bit.ly/2ObxFY5

15. SAGA pattern is our new reality!

16. Actually we have
to deal with
state machines
https://bit.ly/2OaAfgG

17. Now I have to control every
operation manually and think
about compensations, Carl!

18. Domain Context is a king
https://speakerdeck.com/mploed/implementing-ddd-with-the-spring-ecosystem

19. Conference attendee example
https://speakerdeck.com/mploed/implementing-ddd-with-the-spring-ecosystem

21. Options to reduce Saga complexity
Reorder steps to minimize business risks
Hide intermediate data with flags or statuses
Use CQRS or data replication for local consistency
constraints
Avoid synchronous communication between services
Rely on retriable idempotent operations
Prefer optimistic locking with data versioning
Use distributed locking tools for critical cases

22. Choreography-based SAGA
https://bit.ly/2XA090m

23. Kafka is a new king

24. Make messaging transactional

25. Use CDC tools and
techniques

26. Orchestration-based SAGA

27. Orchestration-based SAGA
https://bit.ly/2KIqKDi

29. Orchestration vs Choreography
Centralized orchestration of the distributed transaction
Services remain simple and don’t know about external
transaction, could be reused in other scenarios
Linear complexity for any number of services
Easier to implement, visualize, test and maintain
Rollback is easier to manage and track
Single point of failure because logic is centralized
Broken encapsulation on orchestrated services

30. Eventuate.io:
usage pattern

31. Eventuate.io:
Saga definition
in code
http://eventuate.io/abouteventuatetram.html

32. Eventuate.io:
Saga definition
in code
https://bit.ly/2Oe2n2A

33. Axon: Saga implementation
@SagaEventHandler for Saga related events handling
SagaRepository to store and retrieve Saga context
SagaManager as core component for Saga processing
SagaStore for different storages support for Saga data
(Jdbc, MongoDb, in memory, JPA)
https://bit.ly/2QFBnea - reference documentation
https://bit.ly/2KF4z12 - sample repository
https://bit.ly/2D6gjp6 – how-to tutorial

34. Axon: Saga
definition in code

35. Camunda: usage pattern
https://github.com/berndruecker/trip-booking-saga-java
https://www.youtube.com/watch?v=tBzMLH1K7NU

36. Camunda: graphical representation

37. Camunda: Saga definition in code

38. Serverless future is coming…

39. AWS Step Functions: usage pattern

40. AWS Step Functions: Saga definition
https://yos.io/2017/10/30/distributed-sagas/

41. Summary and take aways
Business transactions in microservices world are much
more complex than local ACID
You don’t always have to use Saga
Pay attention to consistent messaging
Try to rely on simple patterns to avoid Saga usage
Use Events/Choreography for simple flows, switch to
Command/Orchestration only for complex scenarios
Don’t reinvent the wheel, prefer existing frameworks

42. @xpinjection
https://xpinjection.com
https://t.me/xpinjection_channel