I just finished building a small Outbox pattern implementation for an e-commerce orders service that uses PostgresDB with Redis Pub/Sub as the message broker. (ofc in golang)
The goal is to stop losing events when something goes wrong between writing to the database and publishing to the message broker, which is a classic problem in event driven systems. This avoids any loss of events in EDAs.
>In my this tiny version, when a checkout creates an order, the service writes both the orders row and an outbox row in the same Postgres transaction.
Now instead of one table of orders we maintain two tables one for order and one for outbox.
>The outbox row stores the topic and a JSON payload with a current processing state like "pending".
>A separate dispatcher process then polls outbox for pending rows using `FOR UPDATE SKIP LOCKED`, publishes each payload to a Redis channel like `orders.created`, and only after a successful publish marks the row as processed.
This famous pattern gives at least once delivery guarantees and keeps the system consistent across, while we can have downstream consumers like inventory, email, and analytics which are built to be idempotent so they can handle occasional duplicates safely.
I really like this approach because it is simple, uses the database we already trust for atomicity, and avoids complex distributed transactions while still being robust.
It was absolute fun implementing a classic outbox solution in Go, inspired by one of the most famous e‑commerce failure scenarios.