You need to update the database and publish an event. How do you keep those two from getting out of sync?

Use the transactional outbox pattern: write the event into an outbox table in the same transaction as the state change, then have a separate relay poll or tail the log and publish it, marking it sent. That way there is one commit, so you can never have a row without an event or an event without a row. The relay gives at least once delivery, so consumers still need to be idempotent.

The trap is that a database commit and a broker publish are two separate systems, so any ordering you pick has a failure mode. Publish first and the transaction can roll back, so consumers act on something that never happened. Commit first and the process can die before publishing, so the event is lost and nothing retries it. The outbox pattern removes the gap: the event row is inserted into an outbox table inside the same transaction as the business change, so either both land or neither does. Then a relay reads unsent rows in order and publishes them, marking them sent, and if it crashes mid publish it just republishes, which is why consumers must be idempotent. If I am on Postgres and want less polling, I use change data capture off the write ahead log with something like Debezium, which is the same guarantee with less bespoke code. The operational details worth planning are pruning the outbox and monitoring relay lag, because an outbox that stops draining looks completely healthy from the application side.