Distributed Sagas: A Protocol for Coordinating Microservices - Caitie McCaffrey - JOTB17
Ғылым және технология
Microservices have become the defacto architecture pattern for building services. However separating business logic into small services that operate with a single logical data set has introduced consistency challenges. Previous attempts to solve this problem like two phase commit have not been widely adopted due to availability and liveness issues.
Instead developers implement feral concurrency control mechanism. This technique can be error prone, and often results in “Death Star” architectures which rely on chained calls to enforce application invariants. These architectures become more complicated over time, and are difficult to modify and extend, and often don't correctly handle all failure scenarios.
In this talk I propose a new solution for this problem, Distributed Sagas, a protocol for coordinating requests among multiple micro services, while ensuring application invariants.
Пікірлер: 44
Great presentation. So much quality information packed within a short presentation. For those who feel it is too fast you can just slow down the video!
Brilliant presentation. Very informative. SEC & the log being the most important of the all, was graphically well presented.
Great talk and the pace is fine for me. I've been though some of these situations as a developer and architect and have a much better way of describing the concepts now. Thanks Catie.
I think the pace is fine as long as the presenter doesn't stumble, and wow, Caitie is on point! It's the second video I've seen with Caitie on sagas, and I'm looking forward to trying this out myself. Thank you!
Great talk, I enjoyed a lot how you explained :)
I've seen some talks on the same topic and this is one of the best, I'm not a native english speaker and talking speed was ok
Very cool presentation!
Excellent talk! Thank you!
You can add isolation to the pattern by using semantic locking. It means refactoring a lot of existing aggregates/entities, but you can essentially just put a state on something like a booked hotel as "BOOKING_PENDING" and use this to create a locking mechanism. Then you treat it as if it doesn't exist until the state changes to a non-pending state. Semantic locking is a general technique and there's plenty of literature on this. But it answers one of the questions on how to enforce a user not being able to see/modify in between states.
Excellent talk!
Nice talk.
Too good!
Great talk. For the compensation on the flight reservation , could you not cancel it without send a create reservation and the flight service would only cancel if it were held.
Can a saga be thought of similarly to the "unit of work" pattern but only in a distributed architecture?
This is where NServiceBus shines alot :)
:O Great!
Great talk. One question I would have asked is related to the actual scaling of the SEC and the recovery per se. In practice it is likely that you would have more than one SEC (to handle the traffic load) node so each one using some distributed persistence medium to store the logs. In this case how to handle the load of the writes on the log? (use sharding of RDBMS, or a distributed log - like kafka). Also how to know I have a process that got interrupted by the SEC dying.
@benjaminrood1648
5 жыл бұрын
Use a distributive log distinct from all of this.
Your content is awesome, nice presentation, small suggestion your fluency of words is quite fast which is the only -ve in the presentation.
This is one video where I don't need to change playback speed.
nice talk with good examples, but i actually had to slow down the playback
First time in my life, I am hearing a video at 0.5x speed! How can someone speak so fast?
How is that possible making a POST call idempotent. Example book a car, pretty much a POST call. Video 16.51
The explanation for cancelling the flight is indeed weird. If we failed to book a flight, and we need to revert the saga, how do we force the booking of the flight to success? It becomes chicken-and-egg.
@AvanishRaju
2 жыл бұрын
Not really - we don't have to force the booking of the flight to succes - we just need to retry till there's a response - either success or failure. Either way, we have a clear state that we can now use to make sure that the flight booking is compensated. (In fact, if we receive a failure response, there's then no need to even try to compensate the flight booking.)
Put speed on 0.75 since the lady speaks too fast and even she cannot take a breath between words... If you put it on 0.75 speed it will be in some cases too fast :D
I don't know what you guys are talking about. I'm watching this video at 1.5x speed.
@irekip
5 жыл бұрын
I'm trying 0.75x, but it's also too fast :)
@AvanishRaju
2 жыл бұрын
Same here!
Even a micro can't handle such an impressive speech traffic by a presenter..
Jeez! slow down a tad! :)
played at 0.5x speed
please slow
all the well known junk
I don't see anything new, people have been doing this stuff for ages with workflow engines.
Caitie slow down; very informative though
it's a really nice talk, but please slow down a little bit, it's ok to catch a breath between every point, I know you must be so excited but seriously, slow it down a bit
she is just non-stop! bla bla bla...poor live audience.
She should slow down. She is talking way too fast.
Are all american women presenters this irritating?
@gogoackman
3 жыл бұрын
dick
@cipherw00t
3 жыл бұрын
@@gogoackman no u