Event-driven retail commerce backend
A multi-channel commerce backend where every state change is idempotent and auditable. Go + TypeScript on Kafka, outbox pattern, retry-safe effects.
The problem
In multi-channel commerce the same order can arrive twice and a partner webhook can fire three times. The ledger still has to stay exactly right under load.
The solution
BFF + Broker + Dispatcher. The broker decouples producers from consumers. The transactional outbox publishes each event once per committed write, and idempotency keys dedupe at every effect boundary. Kafka carries the event log; Go and TypeScript services consume it. Retries are safe by construction, so a flaky partner degrades gracefully instead of corrupting state.
- Constraint
- The legacy path couldn't scale checkout under load and had no regulator-traceable audit trail. The cutover couldn't stop the business selling. The same order can arrive twice and a webhook can fire repeatedly; the ledger must stay exactly right anyway.
- Decision
- Carve domain capabilities into a BFF + Broker + Dispatcher. Publish via a transactional outbox, once per committed write. Make every downstream effect idempotent so retries are safe by construction. Rejected: a big-bang rewrite (the business can't stop selling), synchronous point-to-point calls (cascading failure), at-least-once delivery without dedupe (double effects).
- Outcome
- Retry-safe, idempotent effects: a flaky partner degrades gracefully instead of corrupting the ledger, and every state change traces through the event log. My integrations shipped without regressing the checkout path.
Overview
An event-driven retail commerce backend across multiple sales surfaces. A BFF fronts the channels, a broker fans domain events out to dispatchers, and the transactional outbox publishes each event once per committed transaction. Idempotency keys make every downstream effect safe to retry. My part: payment, push-notification, and marketplace integrations inside this architecture.