Você precisa atualizar o banco de dados e publicar um evento. Como você impede que os dois saiam de sincronia?

Use o padrão transactional outbox: grave o evento numa tabela de outbox dentro da mesma transação da mudança de estado, e depois tenha um relay separado que faz polling ou lê o log e publica, marcando como enviado. Assim existe um único commit, então você nunca tem uma linha sem evento nem um evento sem linha. O relay dá entrega pelo menos uma vez, então os consumidores ainda precisam ser idempotentes.

A armadilha é que um commit de banco e uma publicação no broker são dois sistemas separados, então qualquer ordem que você escolha tem um modo de falha. Publique primeiro e a transação pode dar rollback, então consumidores agem sobre algo que nunca aconteceu. Comite primeiro e o processo pode morrer antes de publicar, então o evento se perde e nada tenta de novo. O padrão outbox elimina essa lacuna: a linha do evento é inserida numa tabela de outbox dentro da mesma transação da mudança de negócio, então ou as duas acontecem ou nenhuma. Depois um relay lê as linhas não enviadas em ordem e publica, marcando como enviadas, e se ele cair no meio da publicação ele só republica, e é por isso que os consumidores precisam ser idempotentes. Se estou no Postgres e quero menos polling, uso change data capture a partir do write ahead log com algo como o Debezium, que é a mesma garantia com menos código sob medida. Os detalhes operacionais que vale planejar são a limpeza do outbox e o monitoramento do atraso do relay, porque um outbox que parou de escoar parece completamente saudável do lado da aplicação.