Orchestrating transactions over Microservices with Sagas and Spring Statemachine

The world has changed from a monolithic architecture to microservices. This change has brought flexibility, scalability, and many other benefits. Now business transactions can span multiple microservices or even 3rd party systems.

However, this change is not for free. CAP Theorem says that a distributed system can achieve only 2 of the following 3 requirements: Consistency, Availability, and Partitioning tolerance (CAP). In addition, when faced with the question of whether you want it right or you want it right now, humans usually want an answer right now rather than right. Which basically opens a world of eventually consistent systems.

In this presentation, I will explore the challenges of implementing distributed business transactions and show how we can use Sagas and State machines to orchestrate them. The presentation covers:
- Transactions in the Distributed world
- Orchestration of business transactions with help of Sagas
- Implementation of a simple orchestrator using Spring Statemachine

Transcript

1. Orchestrating transactions over Microservices with Sagas and Spring Statemachine Oleksandr Sytnik. July 2022
2. Senior Software engineer - Rabobank (NL), SME Insights - BE, Ops Experience: - 16 years in IT - Java, Azure, SaaS, recently excited about Kotlin - EMV, POS, SmartCards - PSM-I, PSPO-I, IREB, AZ-104, AZ-204, etc. Hobbies: - Travelling (car/motorcycle) - Photography - AI, Robotics - Software Development in general 1
3. § Transactions in the Distributed world § ACID vs BASE, CAP Theorem § Orchestration of business transactions § Sagas as State Machine § Spring Statemachine. Live coding § Q&A 2
5. Buying inventory from one or multiple supplier(s) Selling goods to a customer for cash Selling goods to a customer on credit Paying wages to employees Obtaining a loan from a lender Selling shares to an investor Booking a business trip including a hotel, a car and a plane ticket Implementing a security incident response Etc. 4
6. ACID • Atomic • Consistent • Isolated • Durable • Strong consistency for transactions is the highest priority • Availability less important • Pessimistic • Complex mechanisms BASE • Basically Available • Soft state • Eventually consistent • Availability and scaling is the highest priority • Weak consistency • Optimistic, Best effort • Simple and fast 5
7. § A distributed system can support only two of the following characteristics: § Consistency: All of the nodes see the same data at the same time, regardless of where the data is stored § Availability: Node failures do not prevent survivors from continuing to operate § Partition tolerance: the system continue to operate despite arbitrary message loss 6
10. Traditional data management solutions focus on ACID semantic Modern distributed systems focuses on BASE considering CAP theorem. In distributed systems, business transactions spanning multiple services require a mechanism to ensure data consistency across services. 9
11. § Saga – represents a high-level business process (booking a trip) § Saga – consists of several low-level Requests § Each Request – updated data within a single service § Each Request – has a Compensating Request § Sagas interact with third-party services, where we control the Saga Execution Coordinator (SEC) and its storage, but not the downstream Transaction Execution Coordinators (TECs) themselves. § Communication between the SEC and TEC(s) takes place over an asynchronous network (e.g. TCP) which is allowed to drop, delay, or reorder messages. § 1987 – the term Saga was used by to represent an alternative for long lived transactions: http://www.cs.cornell.edu/andru/cs711 /2002fa/reading/sagas.pdf § 2015 - sagas have been applied to solve consistency problem in distributed systems: https://github.com/aphyr/dist- sagas/blob/master/sagas.pdf 10
12. § Either all Requests in the Saga are successfully completed, or § A subset of Requests and their Compensating Requests are executed. § NOTE: § Requests and Compensating Requests must be idempotent § Compensating Requests must be commutative § Compensating Requests CANNOT abort § Idempotent - can be applied multiple times without changing the result § Commutative - changing the order of the operands does not change the result 11
13. Richardson, C. (2019) Microservices Patterns. Manning 12
14. AC (not I) D Anomalies: § Lost updates § Dirty reads § Fuzzy/nonrepeatable reads Countermeasures: § Semantic lock § Commutative updates § Pessimistic view § Reread value § Version file § By value 13
15. Event-driven choreography Orchestration • No central coordinator • Each service produces events • Each service listens to other service’s events • Each service decides if an action should be taken or not • Central coordinator • Responsible for the decision making • Responsible for sequencing business logic • (+) Simple, loosely coupled • (+) Good for simple systems • (-) Cyclic dependencies • (-) Hard to understand – logic is spread out • (-) Components are more complex • (+) Easier to implement • (+) Easier to understand • (-) Single point of failure • (-) Risk of over-centralization Most popular ways 14
16. § Finite State Machien (FSM) / Finit State Automata (FSA) / State Machine: § abstract machine that can be in exactly one of a finite number of states at any given time. § can change from one state to another in response to some inputs. § the change from one state to another is called a transition. § defined by a list of its states, its initial state, and the inputs that trigger each transition. § Events § States § Action § Transitions 15
17. Extended SM: • Composite state • Guards / Conditions • Fork / Join • History state 16
18. You are already trying to implement a state machine when you: Use Boolean flags or enums to model situations. Have variables to control some part of your application lifecycle. Loop through an if-else structure (or, worse, multiple such structures), check whether a flag or enum is set, and then make further expectations. Spaghetti code in the domain model, specifically a lot of conditional logic in "generic-update" functions. A project is a good candidate to use a state machine when: You can represent the application or part of its structure as states. You want to split complex logic into smaller manageable tasks. The application is already suffering concurrency issues with (for example) something happening asynchronously. 17
19. http://antkorwin.com/statemachine/statemachine.html 18
20. Java • Distributed application with dedicated orchestrator: SSM • Distributed application with distributed orchestrator: SSM + Zookeper AWS • Step Functions to orchestrate execution of Lambda functions in serverless environment Google Cloud • Google Cloud Workflows to orchestrate and automate Google Cloud and HTTP-based API services with serverless workflows. Microsoft Azure • Durable Functions is an extension of Azure Functions that lets you write stateful functions in a serverless compute environment. 19
21. § Easy to use flat one level state machine for simple use cases. § Hierarchical state machine structure to ease complex state configuration. § State machine regions to provide even more complex state configurations. § Usage of triggers, transitions, guards and actions. § Type safe configuration adapter. § Builder pattern for easy instantiation for use outside of Spring Application context. § Recipes for usual use cases. § Distributed state machine based on a Zookeeper. § State machine event listeners. § UML Eclipse Papyrus modelling. § Store machine config in a persistent storage. § Spring IOC integration to associate beans with a state machine. 20
22. Module Description spring-statemachine-core The core system of Spring Statemachine. spring-statemachine-recipes-common Common recipes that do not require dependencies outside of the core framework. spring-statemachine-kryo Kryo serializers for Spring Statemachine. spring-statemachine-data-common Common support module for Spring Data. spring-statemachine-data-jpa Support module for Spring Data JPA. spring-statemachine-data-redis Support module for Spring Data Redis. spring-statemachine-data-mongodb Support module for Spring Data MongoDB. spring-statemachine-zookeeper Zookeeper integration for a distributed state machine. spring-statemachine-test Support module for state machine testing. spring-statemachine-cluster Support module for Spring Cloud Cluster. Note that Spring Cloud Cluster has been superseded by Spring Integration. spring-statemachine-uml Support module for UI UML modelling with Eclipse Papyrus. spring-statemachine-autoconfigure Support module for Spring Boot. spring-statemachine-bom Bill of Materials pom. spring-statemachine-starter Spring Boot starter. 21
23. § 2.5.x - will be there for foreseeable future. § 3.0.x - Spring Statemachine Goes Reactive with 3.0.0 § based on Reactor § Flux<StateMachineEventResult<S, E>> sendEvent(Mono<Message<E>> event) § Flux<StateMachineEventResult<S, E>> sendEvents(Flux<Message<E>> events) 27-03-2022 22
24. § 2.5.x - is still there. § 3.2.0 – currently supported version: § based on Reactor § Flux<StateMachineEventResult<S, E>> sendEvent(Mono<Message<E>> event) § Flux<StateMachineEventResult<S, E>> sendEvents(Flux<Message<E>> events) 16-07-2022 23
25. § Before you write any code, create a diagram of the states of your entity and the valid transitions between those states § Consider what behaviours should be present for each state § Detail the events that will occur as a result of state transitions § Non-Reactive: go for 2.5.x § Reactive: 3.2.x 24
27. 1. Add a dependency <dependency> <groupId>org.springframework.statemachine</groupId> <artifactId>spring-statemachine-starter</artifactId> <version>2.5.0</version> </dependency> 2. Create 2 enums to represent states and events public enum DomainEvent {COIN, PUSH} public enum DomainState {LOCKED, UNLOCKED} 3. Create a configuration class and annotate it with @EnableStateMachine @Configuration @EnableStateMachine public class TravelAgentStateMachineConfig extends EnumStateMachineConfigurerAdapter<TravelReservationEvent, TravelReservationState> { } https://github.com/Oleksandr82/turnstile-ssm.git * Non-reactive, 2.5.x https://github.com/Oleksandr82/turnstile-ssm-reactive Non-reactive (2.5.0) Reactive (3.2.0) 26
28. § Configure States public void configure(StateMachineStateConfigurer<DomainState, DomainEvent> states) § Configure transitions public void configure(StateMachineTransitionConfigurer<DomainState, DomainEvent> transitions) demo/01-initial-state 27
29. § 1. Add a dependency <dependency> <groupId>org.springframework.statemachine</groupId> <artifactId> spring-statemachine-test </artifactId> <version>2.4.0</version> </dependency> § 2. Write a test § 3. Enjoy J Wait a moment… It is still far away from microservices… demo/02-dependency-and-enums 28
30. Let’s add a controller: Just autowire the StateMachine and send events to it. demo/03-rest-controller 29
31. demo/04-actions 30
32. demo/05-multiuser-support 31
33. demo/06-persist 32
34. § Guards § Hierarchical States § Entry/Exit Actions § Parallel tasks handling § Extended State and State Context § State Machine Security build atop of Spring Security § Support of Monitoring and Tracing § Support of Distributes State Machines § Support modeling via UI (trhough the Eclipse Papyrus framework) § Persistance with JPA, Redis, MongoDB § etc. 33
35. https://github.com/Oleksandr82/ignite-travel-agency-ssm.git 34
38. § Spring Statemachine: https://spring.io/projects/spring-statemachine § Spring Statemachine 2.5.0 (non-reactve): https://docs.spring.io/spring-statemachine/docs/2.5.0/reference/ § Spring Statemachine 3.2.0 (reactve): https://docs.spring.io/spring-statemachine/docs/3.2.0/reference/ § Spring Statemachine Intro: http://antkorwin.com/statemachine/statemachine.html § Github: https://github.com/spring-projects/spring-statemachine § AWS Step Functions Developer Guide: https://docs.aws.amazon.com/step-functions/latest/dg/step-functions-dg.pdf § Google Cloud: https://cloud.google.com/blog/topics/developers-practitioners/service-orchestration-google-cloud § Azure Functions: https://azure.microsoft.com/en-us/services/functions/ § Azure Durable Functions: https://medium.com/globant/azure-durable-functions-610291c1123a § Isolation in database systems: https://en.wikipedia.org/wiki/Isolation_(database_systems) § State Machine Diagrams: https://drawio-app.com/uml-state-diagrams-with-draw-io/ § UML 2.0 State Machine Diagrams: https://sparxsystems.com/resources/tutorials/uml2/state-diagram.html 37
39. Section 4. Managing transaction with sagas. 38
40. Thank you for the attention! Contacts: LinkedIn Mail: alexandr.sytnik@gmail.com 39