RabbitMQ
Exchanges, queues, routing keys, AMQP patterns.
Theory
RabbitMQ is an AMQP message broker routing messages from producers to consumers via exchanges and queues. Unlike Kafka's log model, messages are deleted after acknowledgment — classic task queue semantics.
Exchange types control routing: direct (exact routing key), fanout (broadcast), topic (wildcard patterns like orders.*), headers (match message attributes). Bindings connect exchanges to queues with routing rules.
Manual acknowledgments ensure at-least-once processing — ack after success, nack with requeue on transient failure. Dead-letter exchanges isolate poison messages. Prefetch count limits in-flight unacked messages per consumer for fair work distribution.
Production rollouts require idempotent automation, peer review, staged apply, and documented rollback — treat changes as production code.
Interviewers want STAR stories linking RabbitMQ to measurable outcomes: fewer outages, faster deploys, lower cost, or reduced toil.
Architecture Diagram
Users / clients
|
RabbitMQ
|
Core services
|
Data + observabilityExamples
# RabbitMQ
# Exchanges, queues, routing keys, AMQP patterns.
# Validate in staging before production rollout.Interview Questions
What problem does RabbitMQ solve?
It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.
Key components of RabbitMQ?
Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.
Common production pitfalls?
Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.
How do you test changes safely?
Staging parity, canary/gradual rollout, automated health checks, and documented rollback.
Metrics to prove success?
Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.
Beginner vs advanced concern?
Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.
Best Practices
- Treat RabbitMQ config as code with review and CI validation.
- Define SLOs and dashboards before production cutover.
- Document rollback and ownership for on-call.
- Use least privilege for credentials.
Common Mistakes
- Adopting RabbitMQ without measurable success criteria.
- No staging environment mirroring production constraints.
- Missing rollback path during incidents.
- Undocumented on-call expectations.
Trade-off Analysis
RabbitMQ improves exchanges, queues, routing keys, amqp patterns. but adds operational and cognitive complexity — justify with load and team size.
Favor simplicity until metrics (p99 latency, error rate, cost) prove the pattern necessary.
Every redundancy layer trades capital/operational cost for availability — align with explicit SLO targets.
Document accepted inconsistency windows and recovery behavior before production cutover.
Cheat Sheet
Practical Exercises
Stand up RabbitMQ locally or in free tier; document commands and failure recovery.
Introduce misconfiguration; practice detection and rollback under time limit.