Lesson 109 - BASE Transactions and Eventual Consistency

[@oleksiim1283]

Awesome, it could not be an even more clear explanation. Well done Mark. Thank You!

[@gerarldlee]

Thanks Mark! I purchased both of your & Neal Ford's book. Also the explanations in this video is very clear.

[@mgiriprasad123]

As usual a great video. Very informative. In event synchronisation pattern - The customer information service is deleting the record in the database and publishing the message to the queue/topic, what happens if either the database or the publish fail?

[@markrichards5014]

In the event-based scenario, I would always do the database action first. That way, if the database action fails, I haven't published the message yet. In the event I cannot publish the message, I would either reverse the database action or store off the event message for publishing at a later time.

[@dimitrikalinin3301]

You still have guarantees with the technologies used. Firstly, there are ACID database transactions. You store your payload and the instruction to place a message into the queue within a single atomic transaction (transactional outbox table). Secondly, the queue uses a publisher confirms mechanism. You do not mark your instruction as executed until you receive confirmation from the message broker (using message relay). Thirdly, the consumer acknowledgment mechanism ensures that the message remains in the queue until it is successfully consumed. Of course, implementing retry mechanisms and ensuring idempotent communication throughout the entire processing chain is essential, but this approach is reliable.