Should db commit and message-queue produce be one transaction?

Question

I am making a microservice based architecture and I'm actively seeking antipatterns and trying to avoid them. In multiple scenarios, I have a database commit followed by a message that is produced to Kafka (but it could be any message broker, really).

If the db commit fails, an error is returned as one would expect. If the Kafka message produce fails, is it an antipattern to keep retrying the produce (which may introduce some other datastore to have this resiliency)?

Or should I undo the db transaction and return an error?

Answer 1

There is no clear-cut answer. It depends on how the interaction produces customer value.

If committing the DB transaction provides sufficient value to your customer, i'd recommend committing the transaction and logging the produce error on a level high enough that a human will take care of re-publishing the message.

Otherwise, if the real value for the customer only comes from the actions the consumers of the message will take i'd recommend rolling the transaction back and showing an error message to the user (since they won't get anything of what they wanted).

Answer 2

Basically all should be packed as a transaction.

However, on a failure you might want to place the work in a state FAILED in order to prevent retries - as you sketched. I would say, that is a new second transaction (@TansactionAttribute (TransactionAttributeType. REQUIRE_NEW)), preferably done when the other transaction is still failing. Rolled back should only be the first transaction of course.

In short: any control flow might might consist out of more than one transactional step.