[gunnarmorling]

Couldn't agree more; to me, communication between microservices should be async most of the times, as otherwise availability of services is impacted by those of others.

This raises the question how services can update their own state (database) and send messages to other services e.g. via Kafka, without relying on distributed transactions. I found the outbox pattern comes in handy for that: services write messages into an "outbox" table within their own database, thus not relying on availability of any other resources besides that database. From the outbox table, events are propagated to receivers asynchronously. There's different ways for implementing this, most efficiently via change data capture (CDC) on the outbox table.

We support this pattern in Debezium (see https://debezium.io/blog/2019/02/19/reliable-microservices-d...) with a routing component and now also an extension for the Quarkus framework (Java stack for implementing cloud-native microservices with JVM and GraalVM).

Feedback on all this would be very welcomed. Outbox to me hits the sweet spot between not relying on availability of any other services, giving instant read-your-own-write semantics for services (as opposed to writing to a queue/commit log first and reading back from there) and putting eventual consistency to communication with other services, where it's typically easy to accept.

Disclaimer: working on Debezium

[NicoJuicy]

Did you need to implement replaying events already?

Or do you use an out of the box solution?