Using sagas to maintain data consistency in a microservice architecture

Size: px

Start display at page:

Download "Using sagas to maintain data consistency in a microservice architecture"

Lindsey Walker
5 years ago
Views:

1 Using sagas to maintain data consistency in a microservice architecture Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action chris@chrisrichardson.net

2 Presentation goal Distributed data management challenges in a microservice architecture Sagas as the transaction model

3 About Chris

4 About Chris Consultant and trainer focusing on modern application architectures including microservices (

5 About Chris Founder of a startup that is creating an open-source/saas platform that simplifies the development of transactional microservices (

6 For more information

7 Agenda ACID is not an option Overview of sagas Coordinating sagas

8 The microservice architecture structures an application as a set of loosely coupled services

9 The microservice architecture tackles complexity through modularization * might improve scalability too

10 Microservice architecture Database per service Browser HTML Store Front UI Customer Service Customer Database REST API Gateway Order Service Order Database REST Mobile Device Service Database

11 Loose coupling = encapsulated data Order Service Customer Service Order Database Order table ordertotal Customer Database Customer table creditlimit

12 How to maintain data consistency?!?!? Invariant: sum(open order.total) <= customer.creditlimit

13 Cannot use ACID transactions Distributed transactions BEGIN TRANSACTION Private to the Order Service SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID =? SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID =? INSERT INTO ORDERS COMMIT TRANSACTION Private to the Customer Service

14 2PC is not an option Guarantees consistency BUT 2PC coordinator is a single point of failure Chatty: at least O(4n) messages, with retries O(n^2) Reduced throughput due to locks Not supported by many NoSQL databases (or message brokers) CAP theorem 2PC impacts availability.

15 Agenda ACID is not an option Overview of sagas Coordinating sagas

16 From a 1987 paper

17 Use Sagas instead of 2PC Distributed transaction Service A XService B Service C Saga Service A Local transaction Service B Local transaction Service C Local transaction

18 Create Order Saga createorder() Order Service Local transaction createorder() Customer Service Local transaction reservecredit() Order Service Local transaction approve order() Order state=pending Customer Order state=approved

19 If only it were this easy

20 Rollback using compensating transactions ACID transactions can simply rollback BUT Developer must write application logic to rollback eventually consistent transactions Careful design required!

21 Saga: Every Ti has a Ci FAILS T1 T2 C1 C2 Compensating transactions T1 T2 C1

22 Create Order Saga - rollback createorder() Insufficient credit Order Service Customer Service Order Service Local transaction createorder() Local transaction reservecredit() FAIL Local transaction reject order() Order Customer Order

23 Sagas complicate API design Request initiates the saga. When to send back the response? Option #1: Send response when saga completes: + Response specifies the outcome - Reduced availability Option #2: Send response immediately after creating the saga (recommended): + Improved availability - Response does not specify the outcome. Client must poll or be notified

24 Revised Create Order API createorder() returns id of newly created order NOT fully validated getorder(id) Called periodically by client to get outcome of validation

25 Minimal impact on UI UI hides asynchronous API from the user Saga will usually appear instantaneous (<= 100ms) If it takes longer UI displays processing popup Server can push notification to UI

26 Sagas complicate the business logic Changes are committed by each step of the saga Other transactions see inconsistent data, e.g. Order.state = PENDING more complex logic Interaction between sagas and other operations e.g. what does it mean to cancel a PENDING Order? Interrupt the Create Order saga Wait for the Create Order saga to complete?

27 Agenda ACID is not an option Overview of sagas Coordinating sagas

28 How to sequence the saga transactions? After the completion of transaction Ti something must decide what step to execute next Success: which T(i+1) - branching Failure: C(i - 1)

29 Orchestration-based saga coordination createorder() CreateOrderSaga Order Service Local transaction createorder() Customer Service Local transaction reservecredit() Order Service Local transaction approve order() Order state=pending Customer Order state=approved

30 Complex coordination logic is centralized

31 Services expose APIs that are invoked by saga

32 CreateOrderSaga orchestrator Create Order Order Service Customer Service OrderService Order state total create() CreateOrder Saga create() approve() reservecredit() creditreserved() Customer creditlimit creditreservations...

33 Saga orchestrators are state machines event [guard] / action reply and action / customerservice. reservecredit() credit reserved / order.approve() RESERVING CREDIT APPROVED Initial action credit limit exceed / order.reject() REJECTED

34 Create Order Saga code State Enum Persistent data Stateless singleton: Behavior Eventuate Saga framework

35 Create Order Saga State machine definition

36 Initializing the saga Create order Invoke saga participant

37 Handling a reply Update Order

38 Customer Service - command handling Reserve credit

39 About Saga orchestrator participant communication command Saga Orchestrator reply Saga Participant Saga Participant Saga must complete even if there are transient failures

40 Use asynchronous messaging

41 Create Order Saga messaging Order Service Commands reserve credit Message Broker Customer Service Create Order Saga Orchestrator Customer Service Request Channel Customer Service Reply Channel Credit Reserved Credit Limit Exceeded Begin TXN Read data Send reply Commit TXN create() approve() reject() Order Replies

42 Messaging must be transactional How to make atomic without 2PC? Service update publish Database Message Broker

43 Option #1: Use database table as a message queue ACID transaction Customer Service INSERT CUSTOMER_CREDIT_RESERVATIONS table Local transaction? Message Publisher Publish INSERT MESSAGE table QUERY DELETE Message Broker ORDER_ID CUSTOMER_ID TOTAL ID TYPE DATA DESTINATION OrderCreated { } See BASE: An Acid Alternative,

44 Publishing messages Poll the MESSAGE table OR Tail the database transaction log

45 Option #2: Event sourcing: event-centric persistence Event table Service Entity id Entity type Event id Event type Event data save events and publish 101 Order 901 OrderCreated 101 Order 902 OrderApproved Event Store 101 Order 903 OrderShipped Every state change event

46 Summary Microservices tackle complexity and accelerate development Database per service is essential for loose coupling Use sagas to maintain data consistency across services Use transactional messaging to make sagas reliable

47 Questions?

ACID Is So Yesterday: Maintaining Data Consistency with Sagas

ACID Is So Yesterday: Maintaining Data Consistency with Sagas Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action chris@chrisrichardson.net http://eventuate.io