Event-Driven e-commerce architecture: Redis, RabbitMQ or AWS SQS in 2026?
TL;DR - Quick summary
- No frozen carts: Event-driven cores accept orders instantly; invoicing, mail and ERP run asynchronously.
- Brokers: Redis for speed, RabbitMQ for rich routing, AWS SQS for cloud scale without running your own bus.
- GMI stack: NestJS, MedusaJS v2 and AWS to survive traffic spikes.
- Proof: SFD at 100,000+ downloads and 4.9★ on the App Store with async background processing during big promos.
The problem: your store waits for accounting to render a PDF
Black Friday pattern: the buyer taps pay, a synchronous monolith spins for eight seconds while the server saves the order, calls ERP, renders a PDF and sends mail. A slow SMTP stalls the whole checkout. Shoppers refresh - double charges or abandonment.
That is direct revenue loss. GMI Software (Gdańsk, 16+ years) ships event-driven flows. The cart acknowledges in roughly 0.1s and emits a compact event: "Order #1234 accepted". Buyers see success immediately while invoicing and email workers consume the queue at their own pace.
Redis vs RabbitMQ vs AWS SQS for commerce
Async collaboration needs a message broker. The right pick depends on scale and hosting:
1. Redis (Pub/Sub / Streams) - raw speed
In-memory data makes Redis the fastest path for simple flows and live status (e.g. order updates in an app).
Watch out: events can vanish on restart without durable persistence and replication discipline.
2. RabbitMQ - complex routing
Mature broker with topics, queues and DLXs. Useful when, say, a B2B order above PLN 10,000 must hit risk review while smaller orders flow straight to fulfilment.
Watch out: you operate the cluster - solid DevOps is non-negotiable.
3. AWS SQS - our cloud default
Fully managed queues, fewer night pages, integrates with Lambda / ECS, scales from tens to hundreds of thousands of messages per minute.
Cost: pay-as-you-go - we model it from webhooks and ERP volume. Pairs naturally with AWS ECS and NestJS.
Delivery cost and fixed-price guarantee
Going event-driven is usually part of a broader move toward microservices and headless cores (e.g. MedusaJS v2).
- Budget: transactional paths decoupled from slow side effects typically land around PLN 160,000-240,000.
- Timeline: audit through stable production usually needs three to six months.
CTOs fear scope creep and hidden refactor costs. GMI Software is the only Polish company in this model that protects the budget: DDT (Discovery, Design & Technology) maps every event flow first, then we issue a fixed-price guarantee.
Frequently asked questions
- What is event-driven architecture?
- A pattern where modules (cart, invoicing, stock) avoid blocking each other with synchronous calls. They emit events to a queue and consumers process them asynchronously.
- Why does async matter for e-commerce stores?
- Shoppers do not wait on shipping labels or invoices during checkout. Faster payment paths (sub-second targets) and less risk that one slow dependency freezes the whole store during traffic spikes (e.g. TV campaigns).
- What is a message broker?
- Middleware between services: it accepts messages, buffers them and delivers to consumers even when a worker is briefly down (RabbitMQ, Redis Streams, AWS SQS, Kafka, etc.).
- Which option (Redis, RabbitMQ, SQS) does GMI Software recommend?
- On AWS we usually pick SQS for scale without operating a broker. Redis when extreme speed matters (cache, real-time). RabbitMQ when you need rich routing on infrastructure you control.
- Does building on AWS mean cloud lock-in?
- We containerise microservices with Docker so code stays portable. SQS simplifies operations, yet domain logic remains yours and you can swap transports to another broker (e.g. RabbitMQ) if plans change.
Content updated: March 31, 2026