How do you choose an event broker for commerce: Redis, RabbitMQ, SQS or Kafka?

Event-driven commerce means the system reacts to business facts: order accepted, payment captured, stock reserved, invoice requested, shipment created, return received. An event describes something that already happened; it is not a command saying "make me a PDF now". That distinction matters because it creates resilient flows, not just delayed slow operations.

In classic checkout, a monolith often does everything synchronously: saves the order, calls ERP, generates an invoice, sends email, updates CRM, reserves stock and refreshes the search index. One slow system can freeze the cart. Event-driven design separates the critical path from side effects. The shopper should get a checkout decision quickly, while the rest of the system catches up through queues and workers.

This is not free magic. Asynchrony introduces retries, duplicates, out-of-order delivery, DLQs, monitoring, idempotency and manual operations. A good project does not ask "which broker is best?". It asks "which guarantees does this specific flow need?".

The worst event-driven design sends everything asynchronously and pretends consistency disappeared. Checkout must clearly separate critical decisions from side effects. Payment authorization, price validation, stock reservation or trade-credit checks may be part of the business decision. PDF invoice, email, CRM update, search indexing and many reporting integrations usually should not block the shopper.

A good model starts with the command side: accept the cart, check conditions, store order intent, confirm payment or pending status, and only then emit events. If ERP is the system of truth for stock or trade credit, decide whether checkout waits for ERP, uses a local read model or accepts the order conditionally with later validation.

At GMI we often design this as a narrow production slice: NestJS order service, PostgreSQL for transactional state, broker for side effects, workers for PDF/ERP/CRM/WMS and an operational dashboard for errors. This is Black Friday architecture, not just "a queue in code".

AWS documents that SQS Standard provides at-least-once delivery, but a message may be delivered more than once and occasionally out of order. That is not a flaw to hide. It is a contract the application must accept. Invoice consumers, ERP sync and email workers must be idempotent.

Idempotency means the same event processed twice does not create two invoices, two payments, two shipments or two emails with conflicting status. In practice, you store event id, order id, version, idempotency key and processing status. The operation can be repeated without changing the business result.

If ordering is critical, choose a per-aggregate model: order events for one order, customer events for one customer, inventory events for one SKU/location. SQS FIFO uses message groups, and Kafka preserves order within a partition for the same key. Global ordering for the whole store is usually unnecessary and expensive.

Every event-driven system must answer one question: what happens when a worker cannot process a message? Unlimited retry can clog the queue. No retry loses temporary ERP failures. Too low a limit moves normal delays to the dead-letter queue. Too high a limit hides a defect for hours.

SQS DLQ lets you isolate messages that could not be processed, analyze the cause and redrive them. AWS recommends setting `maxReceiveCount` high enough so the system can survive transient errors. RabbitMQ has dead-letter exchanges and acknowledgements: the broker removes a message only after the consumer confirms processing with an ack.

Operationally, a DLQ is not a trash bin. It is a task list for the system and the team. It needs an alert, owner, runbook, message-age metrics and a decision: replay, manual fix, cancel, refund, contact customer. Without that, event-driven design only moves failures from checkout to backoffice.

In commerce, an event is a contract between teams. `order.accepted.v1` needs an owner, schema, version, required fields, time semantics and compatibility rules. If an ERP worker assumes `customerVatId` always exists and checkout stops sending it, the failure appears far away from the change.

Not every event should contain full data. Sometimes an id is enough and the worker fetches a snapshot from an API. Sometimes you need an immutable payload because price, tax and shipping address must reflect the purchase moment. That is a domain decision, not a technical preference.

Good events are not named after implementation. `sendEmail` is a command to a specific worker. `orderPaid`, `invoiceRequested`, `shipmentCreated`, `returnReceived` are business facts. That is what separates event-driven architecture from distributed spaghetti.

It is not enough to know that a queue exists. In commerce you need to know how many orders wait for ERP, how many invoices are in DLQ, the age of the oldest message, what percentage of retries succeed, how many events a worker processes per minute and whether backlog grows faster than consumption.

The most important metrics are business metrics: payment captured but order not exported, order accepted but invoice missing, shipment created but customer not notified, return received but refund not started. Broker metrics help, but alone they do not tell the CFO how much money is stuck in integration.

At GMI we design the operational dashboard together with queues. Support and operations must see order status, last event, retry count, error reason and safe actions: replay, skip, manual fix, contact customer. That turns event-driven from technology into an operating process.

Extracting a safe event-driven path for checkout, ERP/PIM/WMS, invoices and email usually starts around PLN 160,000-300,000, depending on integration count and current monolith quality. The broker itself is cheap. The expensive parts are domain model, idempotency, observability, retries, DLQs, tests and the operating model for fixing failures.

The smallest useful scope is: flow map, event contract, broker, a few workers, DLQ, monitoring, idempotency store and checkout regression scenarios. Larger scopes include order service, outbox pattern, saga/workflow, ERP sync, WMS, marketplace, multi-country, Kafka/data platform and historical event migration.

GMI provides an initial estimate within 48 hours, but fixed price after DDT. In DDT we decide which operations can be async, which must remain synchronous, what needs per-aggregate ordering, who owns the DLQ and which metrics prove the store is peak-ready.

We start with DDT and a process map: checkout, payment, stock reservation, ERP, PIM, WMS, invoice, email, CRM, search, mobile push and reporting. Then we separate the critical path from side effects and choose transport based on required guarantees, not fashion.

Technically, we often combine NestJS, PostgreSQL, Redis, RabbitMQ, AWS SQS, sometimes Kafka, Next.js, React Native and MedusaJS. In commerce, the queue is only part of the model: transactional outbox, idempotency, retry, DLQ, audit log, operational dashboard and checkout regression tests matter just as much.

Commercially, the client gets source-code ownership, no vendor lock-in, fixed price after DDT and post-launch maintenance. This matters because event-driven commerce lives long after launch: new sales channels, ERP integrations, marketplace flows and mobile apps keep adding new events.