Necesitas actualizar la base de datos y publicar un evento. ¿Cómo evitas que las dos cosas se descuadren?

Usa el patrón outbox transaccional: escribe el evento en una tabla outbox dentro de la misma transacción que el cambio de estado, y que un relay aparte haga polling o lea el log y lo publique, marcándolo como enviado. Así hay un único commit, de modo que nunca puedes tener una fila sin evento ni un evento sin fila. El relay da entrega al menos una vez, así que los consumidores siguen necesitando ser idempotentes.

La trampa es que un commit de base de datos y una publicación en el broker son dos sistemas distintos, así que cualquier orden que elijas tiene un modo de fallo. Publica primero y la transacción puede deshacerse, así que los consumidores actúan sobre algo que nunca ocurrió. Confirma primero y el proceso puede morir antes de publicar, así que el evento se pierde y nadie lo reintenta. El patrón outbox elimina el hueco: la fila del evento se inserta en una tabla outbox dentro de la misma transacción que el cambio de negocio, así que o aterrizan las dos o ninguna. Después un relay lee en orden las filas sin enviar y las publica, marcándolas como enviadas, y si se cae a mitad de publicación simplemente vuelve a publicar, que es justo por lo que los consumidores deben ser idempotentes. Si estoy en Postgres y quiero menos polling, uso captura de cambios de datos sobre el write ahead log con algo como Debezium, que da la misma garantía con menos código a medida. Los detalles operativos que merece la pena planificar son podar el outbox y monitorizar el retraso del relay, porque un outbox que deja de vaciarse parece totalmente sano desde el lado de la aplicación.