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.
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
Transactions • Order process changes customer and product • Probably need a transaction Customer Service Product Service Order Process Delivery Process Invoicing
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
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
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
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…?
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?
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
Entity Service: DON’T • Bad performance • Bad reliability • Needs distributed tx – impossible Customer Service Product Service Order Process Delivery Process Invoicing
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
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
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)
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
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!
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?
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
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
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
ACID vs CAP Consistency • ACID Consistency: No violated constraints • i.e. invariants, referential integrity etc • CAP consistency: All nodes have the same data
Conclusion •No ACID transactions between microservices •Saga: String of transactions + compensation •Saga might be the better option to model domain logic
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!
ewolff
etaroid
minorun365
yoshimi0227
upura
hhiroshell
replu
sekido
knsg16
a_bicky
tsukubachallenge
fujiwara3
yoshiitaka
lauravandoore
matthewcrist
eileencodes
hursman
3n
geeforr
mclloyd
kneath
tenderlove
aki_iinuma
andyhume
moore