Event-driven commerce: Redis, RabbitMQ and AWS SQS in practice

Event-driven architecture means services communicate via queued events instead of synchronous HTTP chains for every user action.
Redis: fast and close to the app
We buffer rate limits, checkout sessions and short async jobs. Redis Streams can bridge until scale needs a dedicated broker.
Persistence and replication matter, losing a queue on Black Friday hurts more than a managed bus fee.
RabbitMQ in hybrid setups
Strong DX, topic routing and DLXs. Fits controlled VPC environments with rich retry patterns.
We add TTL and prefetch limits so one bad consumer cannot clog queues.
SQS on AWS
Managed SLA and Lambda/ECS integration reduce night ops. We use SNS+SQS for order event fan-out.
Cost scales with message volume, we model it from webhook and ERP traffic estimates.
Frequently asked questions
- Should everything be async?
- No. we keep synchronous paths where the user needs an immediate decision (e.g. cart availability).
- How do you debug distributed flows?
- Correlation IDs, structured logs and cross-service tracing, or you will not find the “lost” order.
- Idempotency?
- Idempotency keys on webhooks and duplicate tolerance are standard, not extras.
Content updated: March 13, 2026