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

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

Haha I see what you did there ;)

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

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

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.

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.

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

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

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

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.

The audience asked many questions afterward in person :)

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

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

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

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

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.

😂