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, a partner webhook can fire three times, a network blip can drop an event mid-flight. The ledger still has to stay exactly right and auditable 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 partner flakiness degrades gracefully instead of corrupting state.
- Constraint
- The legacy path couldn't scale checkout under load and lacked a regulator-traceable audit trail. The cutover couldn't stop the business selling. The same order can arrive twice and a partner webhook can fire repeatedly, yet the ledger must stay exactly right under load.
- Decision
- Carve domain capabilities into a BFF + Broker + Dispatcher. Decouple producers from consumers, 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), and at-least-once delivery without dedupe (double effects).
- Outcome
- Retry-safe, idempotent effects mean a flaky partner degrades gracefully instead of corrupting the ledger, and every state change traces through the event log. My integrations shipped in 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; the transactional outbox publishes each event once per committed transaction, and idempotency keys make every downstream effect safe to retry. I worked on the backend — payment, push-notification and marketplace integrations — inside this architecture.