4 ms·
As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read
by lolive 8y ago
As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]
- ako 8y agoReality is that the IT solution of any company consists of multiple separate applications which need to be coordinated into one working solution. From this reality it's good to design everything as if it's a (micro|macro)service part of a larger landscape of apps. Reality is also that you can never have transactions for everything across all your systems, so transaction alternatives like compensations are always something to deal with.
- boubiyeah 8y agoExactly. And there are tons of techniques to do so. For instance, Stripe is a payment service (you would think a payment service is the number one choice for transactions/locks/etc right?) implemented on the good ol unreliable internet. you can look at how they do it (idempotency, etc) Transactions are a nice and convenient shortcut when they're applicable but they're far from mandatory.
- threeseed 8y agoMany options exist for this e.g. Apache Curator, Redis Distlock, Ignite/Hazelcast Plus of course options around Paxos etc: https://github.com/dgryski/awesome-consensus https://github.com/dgryski/awesome-consensus
- HolyHaddock 8y agoYou may also want to look into the Saga pattern - I found https://www.youtube.com/watch?v=xDuwrtwYHu8 https://www.youtube.com/watch?v=xDuwrtwYHu8 to be a handy high level overview for applying it to microservices. Although personally, I've never felt the need to try and apply it specifically, but the idea is interesting.
- nomercy400 8y agoNow that was an interesting talk. Thank you.
- jschmitz28 8y agoNice, thanks for sharing! I had not heard of this pattern before. The only nit I have on that video is that after a great motivation and summary, their example application at the end (processing game statistics in Halo) didn’t seem to need Sagas at all. Their transactions (both at the game level and at the player level) were fully idempotent and could be implemented in a vanilla queue/log processor without defining any compensating transactions, unless there were additional complexities not mentioned in the talk.
- jj12345 8y agoThanks for sharing this video. When she's discussing Compensations she mentions that the Transaction (T_i) can't have an input dependency on T_i-1. What are some things I should be thinking about when I have hard, ordered dependencies between microservice tasks? For example, microservice 2 (M2) requires output from M1, so the final ordering would be something like: M1 -> M2 -> M1. Currently, I'm using a high-level, coordinating service to accomplish these long-running async tasks, with each M just sending messages to the top-level coordinator. I'd like to switch to a better pattern though, as I scale out services.
- andy_ppp 8y agoYou can't IMO. We have eventual consistency by all writes being commands that can be picked up by services listening to a Kafka queue but this represents LOADS of extra investment and work above building a monolith.
- je42 8y agoyou avoid them. you design your system (a set of microservices) in such a way that you don't need a transaction across service boundaries ( or rather database boundaries )
- base698 8y agoThere are patterns to do with this: Saga Pattern and Command Query Responsibility. In general the separation of the domain should be such that you don't need a transaction across services.