Data Consistency in Microservices Architecture (Grygoriy Gonchar)

[@arisskarpetis]

Moving functions that require data consistency in the same Microservice was great information.

[@amanbains5474]

Why didn’t they ask any event failure type rollback questions in microservices !! This is a really great presentation !!Too much content here in approx 30 minutes !! I have gone through this 5 times !!! Excellent stufff !!

[@grygoriygonchar6994]

Thanks for your warm feedback! And sorry for making it that concise, that's not just you who shared that.

[@mehrdadk.6816]

In germany people tend to be quite. stupid developers who don't listen and yet make a mistake and leave the company

[@theaungmyatmoe]

You can accomplish rollback with compensation

[@PointlessMuffin]

Data consistency is number one priority ;)

[@VarunKalia26]

Haha I see what you did there ;)

[@mehrdadk.6816]

Approaches for dealing with data inconsistency 1. saga 2. reconcilation 3. application event log 4. 2PC/XA 5. event first

[@Joseph-oz7tx]

Thanks, Grygoriy, that's a great speech

[@raymondyoo5461]

Wow, this is such an amazing speech. Thanks a lot for sharing your wisdom 👍👍 23:36 here is the summary of the lecture but it would not be so easy if you haven’t followed the whole journey

[@talgatsabyrov9957]

Эх, наших всегда можно распознать по акценту :) Классное видео, большое спасибо :)

[@deniskoval4908]

говорит на русском, английскими словами)

[@Endvvell]

НАУ може пишатися такими випускниками як він

[@Food_Nature_Lifestyle6]

Hi Grygoriy Gonchar, thanks for the nice video on data consistency. I have a question : Where is the "Application Event Log" containing the order details (Request, Payment, Flight etc) stored ? I mean in which service ? In the example you mentioned, in "makemytrip" there are 5 services, where is the "Application Event Log" Maintained ? Is it maintained by a separate microservice (SAGA) or in one of the 5 microservices (Order, Payment, Hotel, Flight, Transfer) ?

[@AmanNidhi]

nice presentation

[@dfhwze]

Yeah but bad audience. There is a sea of questions sailed by!

[@AjayKumar-fd9mv]

Thanks for this great talk

[@TV-lv4mf]

Great sharing video and thank for tutorial friend, nice meet you ~~^^ ^^

[@tobiowolawi5044]

there isn't a fully exact way you can achieve complete data consistency with micro-service without a level of decoupling trust me. using some kind of locking mechanism and consumer acknowledgement could help to some extent though. for example, use ACID features to lock a transaction on your service db, send and event to a queue like rabbitmq or kafka and wait for acknowledgement before persisting your data in your service before unlocking or if error occurs then unlock and report the error. this same scenario for an event listener as well

[@pinkylover911]

the presenter is very well educated, please add his name for reference :) thanks for the great talk

[@nitinkulkarni7942]

@18:21, how will the "orders" event cancelled if payments did not go thru or vice-versa. In other words what happens if number 4 errors out in one of the 2 places

[@grygoriygonchar6994]

It would be a payment service responsibility to publish an event into Orders steam/topic to inform other services that event is canceled OR it would be an order service responsibility to monitor some Payments steam/topic to detect failed payment and cancel the order. Depending on where do you want to have this complexity and if you want payments service know a bit about orders or orders to know about the payment. Looks like payments already know about orders so 1st scenario looks slightly better to me

[@nishanth2884]

@@grygoriygonchar6994 Isn't that similar to a compensating transaction in the saga pattern except that this is event driven ?

[@rdean150]

Or the Order event processor only responds to Payment Succeeded events in the first place. Or possibly it responds to the same Order Initiated event that triggers the Payment processor by creating/storing an Order in a pending / incomplete state. When it encounters a Payment Succeeded event, the Order event processor will load the pending order and advance it to an actionable state and possibly publish a new event that will signal a different processor to act upon. If the Order event processor receives a Payment Failed event, it will load the pending order and update it to a rejected state. This does introduce a potential race condition, however, that an Order event processor could encounter a Payment Succeeded event before one of its sibling processors has successfully finished processing the Order Initiated event, and hence there is no pending order for it to load and update. So I think the first approach may be the better one. But the downside of only responding to Payment Succeeded events is that if the payment failed, there will be no record of the Order existing at all, other than in the event log itself.

[@romantsyupryk3009]

Thanks so much for this tutorial.

[@aroundthisprettyplanet]

Awesome presentation. No questions from the audience, made me surprise! Anyway, He mention in Kafka vs RabbitMQ, with Kafka there are no retries out of the box. How come that happen?

[@grygoriygonchar6994]

In Kafka, there is no easy way to retry processing a specific message without stop moving the cursor and blocking the whole partition processing. Sure you can retry processing a message easily by not moving the cursor forward, but that would delay processing the next messages in that partition. In contrast in message brokers like RabbitMQ you can do that.

[@rdean150]

What he said ^ I'll just add that different use cases have different requirements for strict ordering of event processing. In some applications, it is critical that the next message not be processed until after the current message has been processed, and hence the cursor should not be allowed to move and the whole partition's queue blocked until the issue is resolved. In other use cases, one or two retries can be attempted and then the failure recorded and the processing allowed to move on past the failed message. And in some use cases, a given event should only be processed one time and the queue continues, regardless of whether it succeeded or failed. All of these approaches are easily achieved using Kafka's offset counter / cursor. But the developer needs to make a conscious decision about which approach is appropriate for a their use case.

[@himanitrainingandconsultan3388]

Need more examples

[@VarunKalia26]

I wonder if anyone if the audience was even listening to this guy? How come you cannot have a question about this topic?

[@grygoriygonchar6994]

The audience asked many questions afterward in person :)

[@SopheakSem]

Does it affect system performance?

[@vadergrd]

usually consistency and availability are a compromise , so in a way yes ... more consistency is less

[@riansyahtohamba8215]

21:15 deal with incositency

[@konstantinchvilyov9602]

Спасибо, коротко, по делу, понятным английским. А на русском есть то же самое или похожее?

[@grygoriygonchar6994]

Из моих докладов, к сожалению, нет

[@konstantinchvilyov9602]

@@grygoriygonchar6994 Спасибо. Может, есть на украинском? :)

[@konstantinchvilyov9602]

@@grygoriygonchar6994 Спасибо, текст доклада очень помоает ebaytech.berlin/data-consistency-in-microservices-architecture-bf99ba31636f

[@yoloswaggins2161]

paid*

[@sameersarmah1446]

Too much content in too little time

[@gaatutube]

I agree ... and some of the patterns were not clear segregated. For example, he talked about reconciliation first ... but later seemed to talk about CQRS etc (stuff in the SAGA pattern). Is reconciliation part of the saga pattern or is it a different pattern altogether? Was confused on this.

[@jayantprakash6425]

good content but poorly presented

[@sbera87]

This is how you not do a presentation.. a slide should illustrate the idea. Too much talk

[@countchivas]

ZZZZZZZZZzzzzzzzzzzzzzzz

[@epi9820]

difficult to understand his English. painful. sorry. Otherwise, it is good

[@vanmierra6927]

Blockchain

[@bahtiyarozdere9303]

No code, no believe.

[@harouna_gn]

😂

[@srianshworld3942]

Too much content in too little time