Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices - Where are my Transactions and my Consitency????

Eberhard Wolff
September 27, 2023

Microservices - Where are my Transactions and my Consitency????

Eberhard Wolff

September 27, 2023

More Decks by Eberhard Wolff

Other Decks in Technology


  1. Microservices: Where Are My Transactions And My Consistency??? Eberhard Wolff

    Head of Architecture https://swaglab.rocks/ https://ewolff.com/
  2. Happened-before ordering in distributed systems earned me a reward. “Time,

    Clocks and the Ordering of Events in a Distributed System” Leslie Lamport
  3. A distributed system is one in which the failure Leslie

    Lamport of a computer you didn't even know existed can render your own computer unusable.
  4. Avoid Consistency Issues! •Store each piece of data in one

    microservice •Microservice uses a database •Database solves the problem …and Kyle Kingsbury helps me to choose the right one.
  5. Entity Service Customer Service Product Service Order Process Delivery Process

    Invoicing Database for scaling …and consistency
  6. Entity Service • Failure can easily propagate. • How can

    you make the system resilient? • Eberhard = default customer, PS5 = default product ? Customer Service Product Service Order Process Delivery Process Invoicing
  7. Transactions • Order process changes customer and product • Probably

    need a transaction Customer Service Product Service Order Process Delivery Process Invoicing
  8. ACID • Properties of classic transactions (tx) • Atomicity: Either

    do full tx full or nothing • Change customer and product • Consistency: No violated constraints • No negative number of products in stock • Otherwise: rollback
  9. ACID • Isolation: Parallel tx isolated • Other orders either

    processed before or after • i.e. no concurrent decrease of stock • Durability: Result of tx stored • e.g. # in stock stored
  10. Two Phase Commit (2PC): Phase 1 Coordinator Resource Resource Coordinator

    identifies resources during transaction execution Can commit? Can commit? Yes/No Yes/No
  11. 2PC Customer Service Product Service Order Process Delivery Process Invoicing

    Transfer Tx ID via network Pass Tx ID to database Start commit / rollback Execute commit / rollback
  12. 2PC •Outdated solutions existed •Borland / Inprise ITS •CORBA OTS,

    JTA, C++ interfaces •Oracle, IMS, CICS, Tuxedo, MQ Series interfaces •🤔 Can I make a fortune implementing that for HTTP, gRPC…?
  13. 2PC •Problem: Blocks resource •Resource must be blocked until 2PC

    is fully done. •Potentially long •What if client crashes? …or if there are network problems?
  14. 2PC •Problem: no fully reliable Commit phase 2: What if

    resource is now unable to commit? Crashes of client / coordinator? •Tx should prevent problems •I.e. reliability is key
  15. Entity Service: DON’T • Bad performance • Bad reliability •

    Needs distributed tx – impossible Customer Service Product Service Order Process Delivery Process Invoicing
  16. Loose Coupling & Modules • Put everything for a set

    of features in one microservice • Including all data • Result: bounded context with loose coupling Order Process Including all customer & product data for orders Delivery Process All data for delivery Invoicing Process All data for invoicing
  17. Saga •Failure: compensation •Compensation undoes the original transaction •e.g. cancel

    an order •Canceled order are stored •i.e. the state change is not undone
  18. Saga •Closer to what happens in the real world •No

    atomicity •No isolation •Also: not all steps have received the order •i.e. transaction in flight: some services have not received it yet •WS-Transaction standard (2002)
  19. 2PC instead of Saga Order Process Delivery Process Invoicing Process

    Rollback! Atomicity: All information about the order is gone! Rollback!
  20. What is the status of my order #42? WAT????? WAT?????????????

    There is no order #42. That happens if the order was not paid. It’s safer and more consistent that way. But we have no data - can’t tell you whether that was the problem. Transactions
  21. Saga vs 2PC •Saga might catch business logic better www.enterpriseintegrationpatterns.com/ramblings/18

    _starbucks.html •Sagas cause less problems if distributed •Don’t do 2PC! •If ACID is needed: Put it in one microservice!
  22. Consistency in DDD •Entity: Object distinguished by identity •Value object:

    distinguished by values •Aggregate: Cluster of entities and value object •Service: Process or transformation outside entity or value object •Transactions / ACID consistency: where?
  23. Consistency in DDD •Use the same aggregate boundaries to govern

    transactions and distribution. •Within an aggregate boundary, apply consistency rules synchronously. Across boundaries, handle updates asynchronously. •I.e. aggregates order, delivery, invoice inconsistent
  24. Consistency in DDD •Entities / value objects inside order aggregate

    are consistent •Aggregate in order process bounded context might be inconsistent •Bounded contexts might be inconsistent
  25. CAP

  26. CAP Theorem: Chose 2 of C, A, P Consistency Partition

    Tolerance Availability Quorum Replication DNS NOT POSSIBLE!* * https://codahale.com/you-cant-sacrifice-partition-tolerance
  27. ACID vs CAP Consistency • ACID Consistency: No violated constraints

    • i.e. invariants, referential integrity etc • CAP consistency: All nodes have the same data
  28. Order Accepted •Start delivery & invoicing •Possible inconsistency: invoice, no

    delivery yet Order Process Delivery Process Invoicing Process
  29. Conclusion •No ACID transactions between microservices •Saga: String of transactions

    + compensation •Saga might be the better option to model domain logic
  30. Conclusion •Aggregates are supposed to be ACID consistent, not bounded

    contexts. •CAP shouldn’t be a huge issue •All depends on good split of business logic!