RabbitMQ FAQ & Answers

RabbitMQ is an open-source message broker implementing AMQP 0.9.1 (Advanced Message Queuing Protocol), written in Erlang/OTP for high reliability. Current version: RabbitMQ 3.13+ (2025). Supports multiple protocols: AMQP 0.9.1, AMQP 1.0 (native in 4.0+), MQTT, STOMP. Core architecture: producers publish to exchanges, exchanges route to queues via bindings, consumers receive from queues. Multi-protocol broker with management UI, clustering, and plugin ecosystem. Install: official packages or Docker. Use for: async task queues, microservices messaging, RPC patterns, event distribution.

Use RabbitMQ when you need: (1) Complex routing - topic/fanout/headers exchanges with flexible patterns. (2) Request-reply patterns - RPC with temporary queues and correlation IDs. (3) Task distribution - round-robin to multiple workers with manual ack. (4) Low latency - sub-10ms message delivery with direct exchanges. (5) Guaranteed delivery - publisher confirms + consumer acks + durable queues. (6) Multi-protocol support - AMQP, MQTT, STOMP in one broker. Don't use for: high-throughput streaming (use Kafka), long-term event storage (use Kafka/event store), analytics pipelines (use Kafka). RabbitMQ excels at traditional messaging patterns, Kafka excels at event streaming and replay.

RabbitMQ 4.0+ features: (1) Multiple protocols: AMQP 0.9.1, native AMQP 1.0 (4.0+), MQTT, STOMP, HTTP. (2) Message patterns: queuing, routing, pub/sub, request/reply, streaming. (3) Reliability: guaranteed delivery, publisher confirms, consumer acknowledgments, durable queues. (4) High availability: clustering (odd nodes: 1, 3, 5, 7), quorum queues (Raft consensus), federation. (5) Management: web UI (port 15672), HTTP API, CLI tools (rabbitmqctl). (6) Queue types: classic, quorum (default for HA), streams (append-only logs). (7) Performance: direct exchanges (fastest), lazy queues, prefetch tuning. (8) Security: TLS, SASL, vhost isolation, user permissions. (9) Monitoring: Prometheus plugin, management metrics. (10) Flexible routing: 4 exchange types (direct, fanout, topic, headers), bindings, routing keys. Complete production-ready message broker.

Exchanges route messages to queues, streams, or other exchanges. Four core types: (1) Direct: routing key exact match, fastest for point-to-point messaging (RPC, task queues). (2) Fanout: broadcast to all bound queues, ignores routing key (pub/sub, event broadcasting). (3) Topic: pattern matching with wildcards (* = one word, # = zero or more words), flexible routing (logs.*.error, logs.#). (4) Headers: route by message header attributes instead of routing key (rarely used, complex matching). Default exchange: nameless direct exchange. Properties: durable (survives broker restart) or transient. Performance: direct exchanges fastest, topic slower due to pattern matching. Exchange-to-exchange bindings supported for multi-hop routing. Declare: channel.exchange_declare(exchange='logs', exchange_type='topic', durable=True). Choose direct for speed, topic for flexibility.

Queue: ordered collection of messages with FIFO semantics. Three types in RabbitMQ 4.0: (1) Classic: traditional queues, (2) Quorum: replicated via Raft consensus (recommended for HA), (3) Streams: append-only logs for replay. Properties: name, durability (durable survives restart, transient ephemeral), auto-delete (removes when no consumers), exclusive (single connection), arguments (x-message-ttl, x-max-length, x-dead-letter-exchange). For durability: use durable queues + persistent messages (delivery_mode=2). Declare: channel.queue_declare(queue='tasks', durable=True). Distribution: multiple consumers receive messages round-robin. Priority queues: set x-max-priority (1-10 recommended). Performance: short queues fastest (empty queue delivers immediately to consumer). Best practice: keep queue size under control, monitor depth.

Bindings: rules that exchanges use to route messages to queues or other exchanges. Connect exchange to queue with routing key. Create: channel.queue_bind(queue='tasks', exchange='work', routing_key='task.process'). Routing behavior by exchange type: (1) Direct: exact routing_key match (binding_key == routing_key), (2) Topic: pattern matching (logs.* matches logs.error, logs.# matches logs.error.critical), (3) Fanout: ignores routing key entirely (broadcasts to all), (4) Headers: matches message headers. Multiple bindings: single queue can bind to multiple exchanges with different routing keys. Exchange-to-exchange bindings: supported for complex multi-hop routing topologies. Binding arguments: optional metadata for headers exchange matching. Essential for flexible message routing and pub/sub patterns.

Message durability requires three components for full protection: (1) Durable exchange: exchange_declare(durable=True), (2) Durable queue: queue_declare(durable=True), (3) Persistent messages: publish with delivery_mode=2 or persistent=True. All three required; missing any component risks message loss on broker restart. Quorum queues: always durable with Raft replication for data safety. Classic queues: durability trades throughput for reliability (disk writes slower). Lazy queues: move messages to disk immediately, better for large backlogs. Transient messages: faster (no disk I/O) but lost on restart, use for non-critical data. Publisher confirms: verify messages persisted to disk. Best practice: use durable exchanges/queues + persistent messages for critical data, use transient for temporary/cache data.

Connection: TCP connection to RabbitMQ broker (~100 KB RAM each, more with TLS). Channel: lightweight virtual connection multiplexed inside TCP connection. Architecture: one connection per application process, multiple channels per connection for concurrent operations. Channel operations: declare exchanges/queues, publish, consume, bind. Thread safety: channels NOT thread-safe, use separate channel per thread. Benefits: channels much lighter than connections (multiplexing reduces overhead). Best practices: (1) Create long-lived connections, avoid frequent connect/disconnect, (2) Use one connection per process, (3) Create separate channel per thread/operation, (4) Close channels after use to prevent leaks, (5) Handle connection recovery (reconnect on failure). Connection leaks cause memory exhaustion. Essential for efficient resource usage.

Consumer acknowledgments ensure reliable message delivery and transfer ownership from broker to consumer. Modes: (1) Manual ack (recommended): consumer explicitly acknowledges after successful processing (channel.basic_ack(delivery_tag)), (2) Auto ack: broker assumes success immediately on delivery (risky - message lost if consumer crashes before processing). Negative ack: channel.basic_nack(delivery_tag, requeue=True/False) to reject and optionally requeue. Redelivered flag: indicates message previously delivered but not acknowledged. Unacknowledged messages: redelivered if consumer disconnects. Prefetch count (QoS): limits unacknowledged messages per consumer (basic_qos(prefetch_count=1) for round-robin). Best practices: use manual ack, acknowledge only after successful processing, handle exceptions with nack, set prefetch for flow control. Critical for preventing message loss.

Routing key: message attribute used by exchanges to route messages to queues via bindings. Format: dot-separated words (max 255 bytes UTF-8), e.g., 'logs.app.error', 'orders.payment.processed', 'user.profile.updated'. Behavior by exchange type: (1) Direct: exact match (routing_key == binding_key), (2) Topic: pattern matching with wildcards (* = one word, # = zero or more words), (3) Fanout: ignored completely (broadcasts), (4) Headers: ignored (uses header attributes). Publish: channel.basic_publish(exchange='logs', routing_key='app.error', body=msg). Best practices: use hierarchical structure (domain.entity.action), consistent naming conventions, avoid overly complex keys (3-4 segments ideal). Common patterns: entity.action ('user.created'), severity.source ('error.database'), region.service.event. Essential for flexible message routing.

Topic exchanges route messages using wildcard pattern matching on routing keys. Routing keys: dot-separated words (e.g., 'logs.app.error', 'user.profile.updated'). Wildcards: (1) * matches exactly one word (logs..error matches logs.app.error, logs.web.error but NOT logs.app.critical.error), (2) # matches zero or more words (logs.# matches logs, logs.app, logs.app.error, logs.app.error.critical). Create: channel.exchange_declare(exchange='logs', exchange_type='topic', durable=True). Bind: channel.queue_bind(queue='errors', exchange='logs', routing_key='.*.error'). Use cases: log aggregation (severity + source), geographic routing (region.country.city), multi-tenant systems. Performance: slower than direct (pattern evaluation), faster than headers. Special cases: # alone = fanout (matches all), single word with no wildcards = direct. Ideal for flexible pub/sub patterns.

Dead Letter Exchange (DLX): normal exchange receiving messages that cannot be delivered. Configure via queue arguments: x-dead-letter-exchange='dlx_exchange', x-dead-letter-routing-key='failed' (optional). Triggers: (1) message rejected with basic_nack(requeue=False), (2) message TTL expires (x-message-ttl), (3) queue length limit exceeded (x-max-length). Retry pattern with delay: main queue → DLX → retry queue (with TTL) → back to main queue via DLX. Headers added: x-death (death count, queue, reason), x-first-death-reason. Use cases: failed message handling, delayed retry logic (TTL + DLX bidirectional setup), audit trails, debugging. Best practices: use policies instead of hardcoded arguments (updateable), add retry counter to prevent infinite loops, monitor DLQ depth. Essential for production error handling.

Clustering: multiple RabbitMQ nodes forming single logical broker. Shared across cluster: exchanges, bindings, users, permissions, vhosts, policies. Queue data: NOT shared unless using quorum queues or streams (classic queues local to one node). Node count: odd numbers recommended (1, 3, 5, 7) for consensus-based features like quorum queues. Node types: disk (persist metadata to disk), RAM (metadata in memory, faster but risky). Formation: rabbitmqctl join_cluster rabbit@node1. Classic mirrored queues: removed in RabbitMQ 4.0. Quorum queues (recommended): Raft consensus algorithm, replicated across nodes, automatic leader election. Network partitions: pause_minority or autoheal strategies. Best practices: deploy in same datacenter (low latency required), use federation for WAN/multi-datacenter. Essential for high availability and horizontal scaling.

Quorum queues: modern replicated queue type using Raft consensus algorithm, default for high availability since RabbitMQ 3.9+. Declare: channel.queue_declare(queue='tasks', arguments={'x-queue-type': 'quorum'}). Features: (1) Data safety via majority replication (3 nodes tolerate 1 failure, 5 tolerate 2), (2) Automatic leader election on node failure, (3) Poison message handling (x-delivery-limit defaults to 20 in RabbitMQ 4.0+), (4) Always durable. Priority support: exactly two priorities per queue (normal and high) without upfront declaration. vs Classic: quorum more reliable but slightly higher resource usage. Classic mirrored queues: removed in RabbitMQ 4.0. Best for: mission-critical workloads requiring HA and data safety. Not for: temporary queues, non-HA use cases. Recommended default for production queues.

RabbitMQ performance optimization: (1) Queue size: keep short (empty queues deliver immediately to consumers, large queues increase RAM usage), (2) Connections: one long-lived TCP connection per process (~100KB RAM each), multiple channels per connection (lightweight multiplexing), (3) Prefetch count: set basic_qos(prefetch_count=1) for round-robin distribution, higher values (10-50) for throughput but risks uneven load, (4) Message size: keep under 1MB for optimal performance, (5) Durability: transient messages faster than persistent (no disk I/O), (6) Exchange types: direct fastest, topic slower (pattern matching), (7) Lazy queues: for large backlogs (moves messages to disk), (8) Multiple queues: use as many queues as CPU cores for parallelism, (9) Batch publishing: combine publisher confirms for better throughput. Monitor: queue depth, memory alarms, message rates, consumer utilization.

Federation: loosely coupled message distribution across multiple RabbitMQ brokers or clusters. Two types: (1) Federated exchanges: receive messages from upstream exchanges, (2) Federated queues: consume from upstream queues. Benefits: WAN-friendly (handles high latency/unreliable networks), different RabbitMQ versions supported, separate administrative domains, no shared Erlang cluster required. Configuration: define upstreams (source brokers), apply federation policies (which exchanges/queues to federate). Use cases: multi-datacenter (geographically distributed), hybrid cloud (on-prem + cloud), B2B messaging (partner integration), disaster recovery. vs Clustering: use federation for WAN/different orgs, clustering for LAN/same datacenter. vs Shovel: federation automatic (policy-driven), shovel manual explicit configuration. Essential for distributed deployments requiring loose coupling.

Management plugin: web-based UI and HTTP API for RabbitMQ administration and monitoring. Enable: rabbitmq-plugins enable rabbitmq_management (included by default). Access: http://localhost:15672 (default port). Default credentials: guest/guest (localhost only, change for production). Features: overview dashboard (connections, channels, queues, message rates), queue/exchange/binding management, publish/consume messages from UI, user/vhost/permissions management, export/import definitions (JSON), cluster monitoring. HTTP API: programmatic access at http://localhost:15672/api. Prometheus endpoint: /api/prometheus for metrics export. Security: restrict guest user to localhost, create admin users, use TLS for remote access. Essential for operational visibility, debugging, and team collaboration. Preferred over rabbitmqctl CLI for most administrative tasks.

Management plugin comprehensive features: (1) Overview dashboard: node stats, connections/channels count, message rates (publish/deliver/ack), memory/disk alarms, (2) Queue management: create/delete/purge, view messages (peek without consuming), get/publish messages, bindings, (3) Exchange management: declare/delete, view bindings, routing test, (4) Connection/channel monitoring: client IPs, protocols, state, message flow graphs, (5) User/vhost management: create users, set permissions (configure/write/read), vhost isolation, (6) Policy management: HA policies, TTL, max length, DLX settings, (7) Import/export: backup/restore definitions as JSON, (8) Cluster view: node status, memory, disk space, Erlang processes, (9) Prometheus metrics: /api/prometheus endpoint for monitoring integration. Real-time graphs: message rates over time, queue depths, consumer utilization. Essential for production operations, debugging, capacity planning.

Publisher confirms: broker-side acknowledgment verifying message successfully received and processed. Enable: channel.confirm_select() before publishing. Confirmation types: basic.ack (message persisted to disk or consumed), basic.nack (broker cannot handle message). Implementation modes: (1) Synchronous: wait for each confirm (slow, not recommended), (2) Asynchronous: batch confirms with callbacks (recommended). Guarantees: persistent messages confirmed when written to disk on all queues, transient messages confirmed when accepted. Use with mandatory flag: returns undeliverable messages instead of silently dropping. Retry strategy: retransmit unconfirmed messages on recovery (handle deduplication consumer-side). vs Transactions: confirms much faster and lighter weight. Best practice: enable confirms for critical messages, implement async callback handling, set timeouts, retry on nack. Essential for 99.99% reliability patterns.

Message TTL (Time To Live): automatic message expiration after specified duration. Set via: (1) Queue-level: x-message-ttl argument in milliseconds (applies to all messages in queue), (2) Per-message: expiration property when publishing (overrides queue TTL, takes minimum of both). Example: queue_declare(arguments={'x-message-ttl': 60000}) for 60 seconds, or publish(body=msg, expiration='30000') for 30 seconds. Expired message handling: dead-lettered to DLX (if configured) or discarded silently. Performance: queue-level TTL more efficient (batch expiration), per-message TTL slower (individual tracking). Quorum queues: support message TTL since RabbitMQ 3.10. Use cases: cache invalidation, time-sensitive events, session data, preventing unbounded queue growth. Best practice: prefer queue-level TTL for uniform expiration, combine with DLX for retry/audit.

Queue TTL (Time To Live): automatic deletion of unused queues after inactivity period. Set via x-expires queue argument in milliseconds. Trigger: queue unused (no consumers, no get operations) for specified duration. Example: queue_declare(arguments={'x-expires': 3600000}) deletes queue after 1 hour of no activity. Behavior: entire queue deleted including all messages, bindings, and metadata. Not supported: quorum queues and streams (only classic queues). Use cases: temporary RPC reply queues (exclusive + TTL), auto-cleanup of abandoned queues, resource leak prevention, temporary worker queues. Different from message TTL: queue TTL deletes entire queue, message TTL expires individual messages. Best practice: combine with exclusive flag for client-specific queues, set longer TTL than expected client lifetime (avoid premature deletion). Essential for preventing orphaned queue accumulation.

Policies: dynamic cluster-wide configuration applied to queues/exchanges matching regex pattern. Components: name, pattern (regex like ^prefix..*), apply-to (queues/exchanges/all), definition (settings JSON), priority (integer, higher wins). Settings: ha-mode (quorum/mirrored), message-ttl, max-length, dead-letter-exchange, federation-upstream. Create: rabbitmqctl set_policy ha-all "^ha." '{"ha-mode":"all"}' or via management UI. Benefits: (1) Applied at runtime without restart, (2) No application code changes, (3) Pattern-based (one policy affects multiple resources), (4) Updateable without redeclaring queues. Priority resolution: when multiple policies match, highest priority wins; same priority uses most recently defined. Use cases: HA configuration for production queues, TTL for session queues, max-length for buffer queues, DLX for error handling. Best practice: prefer policies over hardcoded x-arguments (policies updateable anytime). Essential for operational flexibility.

Shovel plugin: reliable message transfer between queue/exchange to another queue/exchange, local or remote RabbitMQ brokers. Types: (1) Static shovel: defined in rabbitmq.config (survives restarts), (2) Dynamic shovel: created at runtime via management UI or HTTP API (deleted on broker restart unless persistent). Configuration: source (AMQP URI, queue/exchange), destination (AMQP URI, queue/exchange), ack-mode. Acknowledgment modes: on-confirm (at-least-once delivery, waits for confirms), on-publish (at-most-once, faster but may lose messages), no-ack (no guarantees). Use cases: data migration (move messages to new cluster), WAN replication, backfill historical data, cross-datacenter messaging, gradual migration. vs Federation: shovel explicit point-to-point config, federation automatic policy-based. vs Clustering: shovel for separate brokers/WAN. Essential for controlled data movement.

Lazy queues: move messages to disk as early as possible, keep minimal messages in RAM (only enough to serve consumers). Enable: queue_declare(arguments={'x-queue-mode': 'lazy'}) or via policy. Behavior: messages written to disk immediately on publish, loaded to RAM only when needed for delivery. Benefits: predictable RAM usage regardless of queue depth, handle millions of messages without memory alarms, stable performance under backlog. Trade-offs: higher latency (disk I/O), reduced throughput compared to normal queues. Use when: (1) Large backlogs expected (millions of messages), (2) Unpredictable message rates (spiky traffic), (3) Limited RAM available, (4) Latency not critical. Avoid when: low latency required, small queues (normal mode faster), high-throughput real-time processing. Quorum queues: naturally move messages to disk under load, modern alternative. Essential for preventing OOM from large queues.

Priority queues: messages delivered based on priority rather than strict FIFO. Classic queues: enable via x-max-priority argument (1-255, recommend 1-10 for best performance). Quorum queues: support exactly 2 priorities (normal and high) without upfront declaration since RabbitMQ 4.0. Set priority: publish(body=msg, priority=5). Behavior: higher priority messages consumed before lower priority when queue has backlog; empty queue delivers immediately regardless of priority. Performance: higher max priority = more memory/CPU overhead (internal data structures). Use cases: urgent vs normal messages (alerts vs logs), SLA-based processing (premium vs standard), job scheduling (high/medium/low priority). Limitations: priority only matters when consumers slower than publishers (backlog exists), not strict ordering within same priority level. Best practice: use 1-10 priority levels max, avoid for high-throughput scenarios. Essential for differentiated service levels.

Common anti-patterns causing production issues: (1) Large queues: keep queue depth low (large queues consume RAM, slow performance), use lazy queues for backlogs. (2) Auto ack: use manual ack to prevent message loss on consumer crash. (3) No DLX: configure dead letter exchanges to capture failed messages for debugging/retry. (4) Connection sharing across threads: channels not thread-safe, use separate channel per thread. (5) Short-lived connections: create long-lived connections (~100KB RAM each), connection churn causes overhead. (6) No prefetch limit: set basic_qos(prefetch_count) to prevent consumer overwhelm and ensure fair distribution. (7) Using as database: RabbitMQ for message passing not long-term storage (use streams for replay requirements). (8) Ignoring publisher confirms: enable confirms for critical messages to prevent silent loss. (9) Not monitoring: track queue depth, memory alarms, consumer lag. (10) Wrong exchange type: use direct for speed, topic for flexibility, fanout for broadcast. Follow CloudAMQP best practices for production reliability.

RabbitMQ monitoring approaches: (1) Management UI: http://localhost:15672 dashboard showing overview, queue depths, message rates, connections, memory/disk usage. (2) HTTP API: programmatic access at /api endpoint for metrics scraping. (3) Prometheus plugin: /api/prometheus endpoint exports metrics for Prometheus/Grafana integration. (4) rabbitmqctl CLI: list_queues, list_connections, status for scripting. Key metrics: queue length (backlog), message rates (publish/deliver/ack rates), memory usage (% of limit), disk space (free bytes), connection/channel count, consumer utilization (% busy), node health. Alarms: memory alarm (publishers blocked), disk alarm (critical state). Alert thresholds: queue depth > 10k messages, memory > 80%, consumer utilization < 20% (underutilized), message age > TTL. Integration: Grafana dashboards, Datadog, New Relic, CloudWatch. Best practice: monitor all metrics, set proactive alerts, visualize trends. Essential for production SLA compliance.

Streams: append-only log data structure introduced in RabbitMQ 3.9 for high-throughput persistent messaging. Declare: queue_declare(queue='events', arguments={'x-queue-type': 'stream'}). Features: (1) Persistent storage on disk (all messages persisted), (2) Offset-based consumption (like Kafka), (3) Replay capability (consumers read from any offset), (4) Non-destructive reads (messages not deleted on consumption), (5) High throughput (millions messages/second). Retention: configure by time (x-max-age) or size (x-max-length-bytes). Stream protocol: dedicated binary protocol separate from AMQP for better performance. RabbitMQ 4.1+: SQL-like filter expressions for server-side filtering. Use cases: event sourcing, audit logs, time-series telemetry, log aggregation, message replay requirements. vs Traditional queues: streams for replay/audit, queues for task distribution. Essential for Kafka-like streaming patterns within RabbitMQ.

Streams vs Queues fundamental differences: (1) Consumption model: streams non-destructive (messages retained after read), queues destructive (deleted after ack). (2) Replay: streams support offset-based replay (read from any position), queues no replay (FIFO consumption only). (3) Multiple consumers: streams allow independent consumers reading from different offsets, queues distribute messages round-robin (each message to one consumer). (4) Retention: streams retain by time/size (x-max-age, x-max-length-bytes), queues ephemeral (messages deleted when consumed). (5) Performance: streams optimized for write throughput (millions/sec), queues optimized for low latency delivery. (6) Protocol: streams use dedicated stream protocol, queues use AMQP 0.9.1/1.0. (7) Use cases: streams for event sourcing/audit logs/replay, queues for task distribution/RPC/load balancing. Choose streams: replay requirements, multiple independent consumers, audit trails. Choose queues: one-time processing, task distribution, point-to-point messaging.

Virtual hosts (vhosts): logical isolation and multi-tenancy mechanism within single RabbitMQ instance. Each vhost is independent namespace containing separate exchanges, queues, bindings, users, permissions. Default vhost: '/' (forward slash). Create: rabbitmqctl add_vhost production. Benefits: (1) Resource isolation (queues in vhost A invisible to vhost B), (2) Security isolation (separate user permissions per vhost), (3) Multi-tenancy (multiple teams/applications on one broker), (4) Environment separation (dev/staging/production on same instance). Connection: specify vhost in AMQP URI (amqp://user:pass@host:5672/vhostname). Limitations: vhosts share same RabbitMQ node resources (RAM, CPU, disk), not for hard resource limits. Use cases: SaaS multi-tenancy, team isolation, environment separation. Essential for organized production deployments and cost-effective multi-tenant architectures.

Virtual host usage workflow: (1) Create vhost: rabbitmqctl add_vhost /production (use forward slash prefix). (2) Create user: rabbitmqctl add_user appuser password123. (3) Grant permissions: rabbitmqctl set_permissions -p /production appuser '.' '.' '.' (configure, write, read regex patterns). (4) Connect: amqp://appuser:password123@host:5672/production (URL-encode vhost name, '/' becomes %2F). Common naming: /dev, /staging, /prod or /tenant-a, /tenant-b for multi-tenancy. Management UI: vhost dropdown selector, create vhosts graphically. CLI operations: add -p /vhostname flag (rabbitmqctl list_queues -p /production). Permission patterns: configure (declare/delete resources), write (publish), read (consume). Use cases: environment isolation (dev/test/prod), multi-tenant SaaS (per-customer vhost), team separation (separate permissions). Best practices: least privilege (specific regex, not .), audit permissions regularly, use policies per vhost. Essential for security and organizational structure.

RabbitMQ vs Kafka key differences: RabbitMQ - Traditional message broker for complex routing and task distribution. Consumption: destructive (messages deleted after ack). Routing: 4 exchange types (direct, fanout, topic, headers) with flexible bindings. Protocols: AMQP 0.9.1, AMQP 1.0, MQTT, STOMP. Queue types: classic, quorum, streams (3.9+). Strengths: low latency (<10ms), complex routing patterns, RPC/request-reply, priority queues. **Kafka** - Distributed event streaming platform for high-throughput logs. Consumption: non-destructive (offset-based replay). Partitioning: topics split into partitions for parallelism. Retention: configurable (time/size). Strengths: massive throughput (millions/sec), long-term retention, stream processing, exactly-once semantics. **Choose RabbitMQ**: task queues, RPC, complex routing, low latency, traditional messaging, priority handling. **Choose Kafka**: event sourcing, log aggregation, stream processing, replay requirements, high throughput (>100k msg/sec). Note: RabbitMQ streams (3.9+) provide Kafka-like capabilities within RabbitMQ.

RabbitMQ is an open-source message broker implementing AMQP 0.9.1 (Advanced Message Queuing Protocol), written in Erlang/OTP for high reliability. Current version: RabbitMQ 3.13+ (2025). Supports multiple protocols: AMQP 0.9.1, AMQP 1.0 (native in 4.0+), MQTT, STOMP. Core architecture: producers publish to exchanges, exchanges route to queues via bindings, consumers receive from queues. Multi-protocol broker with management UI, clustering, and plugin ecosystem. Install: official packages or Docker. Use for: async task queues, microservices messaging, RPC patterns, event distribution.

Use RabbitMQ when you need: (1) Complex routing - topic/fanout/headers exchanges with flexible patterns. (2) Request-reply patterns - RPC with temporary queues and correlation IDs. (3) Task distribution - round-robin to multiple workers with manual ack. (4) Low latency - sub-10ms message delivery with direct exchanges. (5) Guaranteed delivery - publisher confirms + consumer acks + durable queues. (6) Multi-protocol support - AMQP, MQTT, STOMP in one broker. Don't use for: high-throughput streaming (use Kafka), long-term event storage (use Kafka/event store), analytics pipelines (use Kafka). RabbitMQ excels at traditional messaging patterns, Kafka excels at event streaming and replay.

RabbitMQ 4.0+ features: (1) Multiple protocols: AMQP 0.9.1, native AMQP 1.0 (4.0+), MQTT, STOMP, HTTP. (2) Message patterns: queuing, routing, pub/sub, request/reply, streaming. (3) Reliability: guaranteed delivery, publisher confirms, consumer acknowledgments, durable queues. (4) High availability: clustering (odd nodes: 1, 3, 5, 7), quorum queues (Raft consensus), federation. (5) Management: web UI (port 15672), HTTP API, CLI tools (rabbitmqctl). (6) Queue types: classic, quorum (default for HA), streams (append-only logs). (7) Performance: direct exchanges (fastest), lazy queues, prefetch tuning. (8) Security: TLS, SASL, vhost isolation, user permissions. (9) Monitoring: Prometheus plugin, management metrics. (10) Flexible routing: 4 exchange types (direct, fanout, topic, headers), bindings, routing keys. Complete production-ready message broker.

Exchanges route messages to queues, streams, or other exchanges. Four core types: (1) Direct: routing key exact match, fastest for point-to-point messaging (RPC, task queues). (2) Fanout: broadcast to all bound queues, ignores routing key (pub/sub, event broadcasting). (3) Topic: pattern matching with wildcards (* = one word, # = zero or more words), flexible routing (logs.*.error, logs.#). (4) Headers: route by message header attributes instead of routing key (rarely used, complex matching). Default exchange: nameless direct exchange. Properties: durable (survives broker restart) or transient. Performance: direct exchanges fastest, topic slower due to pattern matching. Exchange-to-exchange bindings supported for multi-hop routing. Declare: channel.exchange_declare(exchange='logs', exchange_type='topic', durable=True). Choose direct for speed, topic for flexibility.

Queue: ordered collection of messages with FIFO semantics. Three types in RabbitMQ 4.0: (1) Classic: traditional queues, (2) Quorum: replicated via Raft consensus (recommended for HA), (3) Streams: append-only logs for replay. Properties: name, durability (durable survives restart, transient ephemeral), auto-delete (removes when no consumers), exclusive (single connection), arguments (x-message-ttl, x-max-length, x-dead-letter-exchange). For durability: use durable queues + persistent messages (delivery_mode=2). Declare: channel.queue_declare(queue='tasks', durable=True). Distribution: multiple consumers receive messages round-robin. Priority queues: set x-max-priority (1-10 recommended). Performance: short queues fastest (empty queue delivers immediately to consumer). Best practice: keep queue size under control, monitor depth.

Bindings: rules that exchanges use to route messages to queues or other exchanges. Connect exchange to queue with routing key. Create: channel.queue_bind(queue='tasks', exchange='work', routing_key='task.process'). Routing behavior by exchange type: (1) Direct: exact routing_key match (binding_key == routing_key), (2) Topic: pattern matching (logs.* matches logs.error, logs.# matches logs.error.critical), (3) Fanout: ignores routing key entirely (broadcasts to all), (4) Headers: matches message headers. Multiple bindings: single queue can bind to multiple exchanges with different routing keys. Exchange-to-exchange bindings: supported for complex multi-hop routing topologies. Binding arguments: optional metadata for headers exchange matching. Essential for flexible message routing and pub/sub patterns.

Message durability requires three components for full protection: (1) Durable exchange: exchange_declare(durable=True), (2) Durable queue: queue_declare(durable=True), (3) Persistent messages: publish with delivery_mode=2 or persistent=True. All three required; missing any component risks message loss on broker restart. Quorum queues: always durable with Raft replication for data safety. Classic queues: durability trades throughput for reliability (disk writes slower). Lazy queues: move messages to disk immediately, better for large backlogs. Transient messages: faster (no disk I/O) but lost on restart, use for non-critical data. Publisher confirms: verify messages persisted to disk. Best practice: use durable exchanges/queues + persistent messages for critical data, use transient for temporary/cache data.

Connection: TCP connection to RabbitMQ broker (~100 KB RAM each, more with TLS). Channel: lightweight virtual connection multiplexed inside TCP connection. Architecture: one connection per application process, multiple channels per connection for concurrent operations. Channel operations: declare exchanges/queues, publish, consume, bind. Thread safety: channels NOT thread-safe, use separate channel per thread. Benefits: channels much lighter than connections (multiplexing reduces overhead). Best practices: (1) Create long-lived connections, avoid frequent connect/disconnect, (2) Use one connection per process, (3) Create separate channel per thread/operation, (4) Close channels after use to prevent leaks, (5) Handle connection recovery (reconnect on failure). Connection leaks cause memory exhaustion. Essential for efficient resource usage.

Consumer acknowledgments ensure reliable message delivery and transfer ownership from broker to consumer. Modes: (1) Manual ack (recommended): consumer explicitly acknowledges after successful processing (channel.basic_ack(delivery_tag)), (2) Auto ack: broker assumes success immediately on delivery (risky - message lost if consumer crashes before processing). Negative ack: channel.basic_nack(delivery_tag, requeue=True/False) to reject and optionally requeue. Redelivered flag: indicates message previously delivered but not acknowledged. Unacknowledged messages: redelivered if consumer disconnects. Prefetch count (QoS): limits unacknowledged messages per consumer (basic_qos(prefetch_count=1) for round-robin). Best practices: use manual ack, acknowledge only after successful processing, handle exceptions with nack, set prefetch for flow control. Critical for preventing message loss.

Routing key: message attribute used by exchanges to route messages to queues via bindings. Format: dot-separated words (max 255 bytes UTF-8), e.g., 'logs.app.error', 'orders.payment.processed', 'user.profile.updated'. Behavior by exchange type: (1) Direct: exact match (routing_key == binding_key), (2) Topic: pattern matching with wildcards (* = one word, # = zero or more words), (3) Fanout: ignored completely (broadcasts), (4) Headers: ignored (uses header attributes). Publish: channel.basic_publish(exchange='logs', routing_key='app.error', body=msg). Best practices: use hierarchical structure (domain.entity.action), consistent naming conventions, avoid overly complex keys (3-4 segments ideal). Common patterns: entity.action ('user.created'), severity.source ('error.database'), region.service.event. Essential for flexible message routing.

Topic exchanges route messages using wildcard pattern matching on routing keys. Routing keys: dot-separated words (e.g., 'logs.app.error', 'user.profile.updated'). Wildcards: (1) * matches exactly one word (logs..error matches logs.app.error, logs.web.error but NOT logs.app.critical.error), (2) # matches zero or more words (logs.# matches logs, logs.app, logs.app.error, logs.app.error.critical). Create: channel.exchange_declare(exchange='logs', exchange_type='topic', durable=True). Bind: channel.queue_bind(queue='errors', exchange='logs', routing_key='.*.error'). Use cases: log aggregation (severity + source), geographic routing (region.country.city), multi-tenant systems. Performance: slower than direct (pattern evaluation), faster than headers. Special cases: # alone = fanout (matches all), single word with no wildcards = direct. Ideal for flexible pub/sub patterns.

Dead Letter Exchange (DLX): normal exchange receiving messages that cannot be delivered. Configure via queue arguments: x-dead-letter-exchange='dlx_exchange', x-dead-letter-routing-key='failed' (optional). Triggers: (1) message rejected with basic_nack(requeue=False), (2) message TTL expires (x-message-ttl), (3) queue length limit exceeded (x-max-length). Retry pattern with delay: main queue → DLX → retry queue (with TTL) → back to main queue via DLX. Headers added: x-death (death count, queue, reason), x-first-death-reason. Use cases: failed message handling, delayed retry logic (TTL + DLX bidirectional setup), audit trails, debugging. Best practices: use policies instead of hardcoded arguments (updateable), add retry counter to prevent infinite loops, monitor DLQ depth. Essential for production error handling.

Clustering: multiple RabbitMQ nodes forming single logical broker. Shared across cluster: exchanges, bindings, users, permissions, vhosts, policies. Queue data: NOT shared unless using quorum queues or streams (classic queues local to one node). Node count: odd numbers recommended (1, 3, 5, 7) for consensus-based features like quorum queues. Node types: disk (persist metadata to disk), RAM (metadata in memory, faster but risky). Formation: rabbitmqctl join_cluster rabbit@node1. Classic mirrored queues: removed in RabbitMQ 4.0. Quorum queues (recommended): Raft consensus algorithm, replicated across nodes, automatic leader election. Network partitions: pause_minority or autoheal strategies. Best practices: deploy in same datacenter (low latency required), use federation for WAN/multi-datacenter. Essential for high availability and horizontal scaling.

Quorum queues: modern replicated queue type using Raft consensus algorithm, default for high availability since RabbitMQ 3.9+. Declare: channel.queue_declare(queue='tasks', arguments={'x-queue-type': 'quorum'}). Features: (1) Data safety via majority replication (3 nodes tolerate 1 failure, 5 tolerate 2), (2) Automatic leader election on node failure, (3) Poison message handling (x-delivery-limit defaults to 20 in RabbitMQ 4.0+), (4) Always durable. Priority support: exactly two priorities per queue (normal and high) without upfront declaration. vs Classic: quorum more reliable but slightly higher resource usage. Classic mirrored queues: removed in RabbitMQ 4.0. Best for: mission-critical workloads requiring HA and data safety. Not for: temporary queues, non-HA use cases. Recommended default for production queues.

RabbitMQ performance optimization: (1) Queue size: keep short (empty queues deliver immediately to consumers, large queues increase RAM usage), (2) Connections: one long-lived TCP connection per process (~100KB RAM each), multiple channels per connection (lightweight multiplexing), (3) Prefetch count: set basic_qos(prefetch_count=1) for round-robin distribution, higher values (10-50) for throughput but risks uneven load, (4) Message size: keep under 1MB for optimal performance, (5) Durability: transient messages faster than persistent (no disk I/O), (6) Exchange types: direct fastest, topic slower (pattern matching), (7) Lazy queues: for large backlogs (moves messages to disk), (8) Multiple queues: use as many queues as CPU cores for parallelism, (9) Batch publishing: combine publisher confirms for better throughput. Monitor: queue depth, memory alarms, message rates, consumer utilization.

Federation: loosely coupled message distribution across multiple RabbitMQ brokers or clusters. Two types: (1) Federated exchanges: receive messages from upstream exchanges, (2) Federated queues: consume from upstream queues. Benefits: WAN-friendly (handles high latency/unreliable networks), different RabbitMQ versions supported, separate administrative domains, no shared Erlang cluster required. Configuration: define upstreams (source brokers), apply federation policies (which exchanges/queues to federate). Use cases: multi-datacenter (geographically distributed), hybrid cloud (on-prem + cloud), B2B messaging (partner integration), disaster recovery. vs Clustering: use federation for WAN/different orgs, clustering for LAN/same datacenter. vs Shovel: federation automatic (policy-driven), shovel manual explicit configuration. Essential for distributed deployments requiring loose coupling.

Management plugin: web-based UI and HTTP API for RabbitMQ administration and monitoring. Enable: rabbitmq-plugins enable rabbitmq_management (included by default). Access: http://localhost:15672 (default port). Default credentials: guest/guest (localhost only, change for production). Features: overview dashboard (connections, channels, queues, message rates), queue/exchange/binding management, publish/consume messages from UI, user/vhost/permissions management, export/import definitions (JSON), cluster monitoring. HTTP API: programmatic access at http://localhost:15672/api. Prometheus endpoint: /api/prometheus for metrics export. Security: restrict guest user to localhost, create admin users, use TLS for remote access. Essential for operational visibility, debugging, and team collaboration. Preferred over rabbitmqctl CLI for most administrative tasks.

Management plugin comprehensive features: (1) Overview dashboard: node stats, connections/channels count, message rates (publish/deliver/ack), memory/disk alarms, (2) Queue management: create/delete/purge, view messages (peek without consuming), get/publish messages, bindings, (3) Exchange management: declare/delete, view bindings, routing test, (4) Connection/channel monitoring: client IPs, protocols, state, message flow graphs, (5) User/vhost management: create users, set permissions (configure/write/read), vhost isolation, (6) Policy management: HA policies, TTL, max length, DLX settings, (7) Import/export: backup/restore definitions as JSON, (8) Cluster view: node status, memory, disk space, Erlang processes, (9) Prometheus metrics: /api/prometheus endpoint for monitoring integration. Real-time graphs: message rates over time, queue depths, consumer utilization. Essential for production operations, debugging, capacity planning.

Publisher confirms: broker-side acknowledgment verifying message successfully received and processed. Enable: channel.confirm_select() before publishing. Confirmation types: basic.ack (message persisted to disk or consumed), basic.nack (broker cannot handle message). Implementation modes: (1) Synchronous: wait for each confirm (slow, not recommended), (2) Asynchronous: batch confirms with callbacks (recommended). Guarantees: persistent messages confirmed when written to disk on all queues, transient messages confirmed when accepted. Use with mandatory flag: returns undeliverable messages instead of silently dropping. Retry strategy: retransmit unconfirmed messages on recovery (handle deduplication consumer-side). vs Transactions: confirms much faster and lighter weight. Best practice: enable confirms for critical messages, implement async callback handling, set timeouts, retry on nack. Essential for 99.99% reliability patterns.

Message TTL (Time To Live): automatic message expiration after specified duration. Set via: (1) Queue-level: x-message-ttl argument in milliseconds (applies to all messages in queue), (2) Per-message: expiration property when publishing (overrides queue TTL, takes minimum of both). Example: queue_declare(arguments={'x-message-ttl': 60000}) for 60 seconds, or publish(body=msg, expiration='30000') for 30 seconds. Expired message handling: dead-lettered to DLX (if configured) or discarded silently. Performance: queue-level TTL more efficient (batch expiration), per-message TTL slower (individual tracking). Quorum queues: support message TTL since RabbitMQ 3.10. Use cases: cache invalidation, time-sensitive events, session data, preventing unbounded queue growth. Best practice: prefer queue-level TTL for uniform expiration, combine with DLX for retry/audit.

Queue TTL (Time To Live): automatic deletion of unused queues after inactivity period. Set via x-expires queue argument in milliseconds. Trigger: queue unused (no consumers, no get operations) for specified duration. Example: queue_declare(arguments={'x-expires': 3600000}) deletes queue after 1 hour of no activity. Behavior: entire queue deleted including all messages, bindings, and metadata. Not supported: quorum queues and streams (only classic queues). Use cases: temporary RPC reply queues (exclusive + TTL), auto-cleanup of abandoned queues, resource leak prevention, temporary worker queues. Different from message TTL: queue TTL deletes entire queue, message TTL expires individual messages. Best practice: combine with exclusive flag for client-specific queues, set longer TTL than expected client lifetime (avoid premature deletion). Essential for preventing orphaned queue accumulation.

Policies: dynamic cluster-wide configuration applied to queues/exchanges matching regex pattern. Components: name, pattern (regex like ^prefix..*), apply-to (queues/exchanges/all), definition (settings JSON), priority (integer, higher wins). Settings: ha-mode (quorum/mirrored), message-ttl, max-length, dead-letter-exchange, federation-upstream. Create: rabbitmqctl set_policy ha-all "^ha." '{"ha-mode":"all"}' or via management UI. Benefits: (1) Applied at runtime without restart, (2) No application code changes, (3) Pattern-based (one policy affects multiple resources), (4) Updateable without redeclaring queues. Priority resolution: when multiple policies match, highest priority wins; same priority uses most recently defined. Use cases: HA configuration for production queues, TTL for session queues, max-length for buffer queues, DLX for error handling. Best practice: prefer policies over hardcoded x-arguments (policies updateable anytime). Essential for operational flexibility.

Shovel plugin: reliable message transfer between queue/exchange to another queue/exchange, local or remote RabbitMQ brokers. Types: (1) Static shovel: defined in rabbitmq.config (survives restarts), (2) Dynamic shovel: created at runtime via management UI or HTTP API (deleted on broker restart unless persistent). Configuration: source (AMQP URI, queue/exchange), destination (AMQP URI, queue/exchange), ack-mode. Acknowledgment modes: on-confirm (at-least-once delivery, waits for confirms), on-publish (at-most-once, faster but may lose messages), no-ack (no guarantees). Use cases: data migration (move messages to new cluster), WAN replication, backfill historical data, cross-datacenter messaging, gradual migration. vs Federation: shovel explicit point-to-point config, federation automatic policy-based. vs Clustering: shovel for separate brokers/WAN. Essential for controlled data movement.

Lazy queues: move messages to disk as early as possible, keep minimal messages in RAM (only enough to serve consumers). Enable: queue_declare(arguments={'x-queue-mode': 'lazy'}) or via policy. Behavior: messages written to disk immediately on publish, loaded to RAM only when needed for delivery. Benefits: predictable RAM usage regardless of queue depth, handle millions of messages without memory alarms, stable performance under backlog. Trade-offs: higher latency (disk I/O), reduced throughput compared to normal queues. Use when: (1) Large backlogs expected (millions of messages), (2) Unpredictable message rates (spiky traffic), (3) Limited RAM available, (4) Latency not critical. Avoid when: low latency required, small queues (normal mode faster), high-throughput real-time processing. Quorum queues: naturally move messages to disk under load, modern alternative. Essential for preventing OOM from large queues.

Priority queues: messages delivered based on priority rather than strict FIFO. Classic queues: enable via x-max-priority argument (1-255, recommend 1-10 for best performance). Quorum queues: support exactly 2 priorities (normal and high) without upfront declaration since RabbitMQ 4.0. Set priority: publish(body=msg, priority=5). Behavior: higher priority messages consumed before lower priority when queue has backlog; empty queue delivers immediately regardless of priority. Performance: higher max priority = more memory/CPU overhead (internal data structures). Use cases: urgent vs normal messages (alerts vs logs), SLA-based processing (premium vs standard), job scheduling (high/medium/low priority). Limitations: priority only matters when consumers slower than publishers (backlog exists), not strict ordering within same priority level. Best practice: use 1-10 priority levels max, avoid for high-throughput scenarios. Essential for differentiated service levels.

Common anti-patterns causing production issues: (1) Large queues: keep queue depth low (large queues consume RAM, slow performance), use lazy queues for backlogs. (2) Auto ack: use manual ack to prevent message loss on consumer crash. (3) No DLX: configure dead letter exchanges to capture failed messages for debugging/retry. (4) Connection sharing across threads: channels not thread-safe, use separate channel per thread. (5) Short-lived connections: create long-lived connections (~100KB RAM each), connection churn causes overhead. (6) No prefetch limit: set basic_qos(prefetch_count) to prevent consumer overwhelm and ensure fair distribution. (7) Using as database: RabbitMQ for message passing not long-term storage (use streams for replay requirements). (8) Ignoring publisher confirms: enable confirms for critical messages to prevent silent loss. (9) Not monitoring: track queue depth, memory alarms, consumer lag. (10) Wrong exchange type: use direct for speed, topic for flexibility, fanout for broadcast. Follow CloudAMQP best practices for production reliability.

RabbitMQ monitoring approaches: (1) Management UI: http://localhost:15672 dashboard showing overview, queue depths, message rates, connections, memory/disk usage. (2) HTTP API: programmatic access at /api endpoint for metrics scraping. (3) Prometheus plugin: /api/prometheus endpoint exports metrics for Prometheus/Grafana integration. (4) rabbitmqctl CLI: list_queues, list_connections, status for scripting. Key metrics: queue length (backlog), message rates (publish/deliver/ack rates), memory usage (% of limit), disk space (free bytes), connection/channel count, consumer utilization (% busy), node health. Alarms: memory alarm (publishers blocked), disk alarm (critical state). Alert thresholds: queue depth > 10k messages, memory > 80%, consumer utilization < 20% (underutilized), message age > TTL. Integration: Grafana dashboards, Datadog, New Relic, CloudWatch. Best practice: monitor all metrics, set proactive alerts, visualize trends. Essential for production SLA compliance.

Streams: append-only log data structure introduced in RabbitMQ 3.9 for high-throughput persistent messaging. Declare: queue_declare(queue='events', arguments={'x-queue-type': 'stream'}). Features: (1) Persistent storage on disk (all messages persisted), (2) Offset-based consumption (like Kafka), (3) Replay capability (consumers read from any offset), (4) Non-destructive reads (messages not deleted on consumption), (5) High throughput (millions messages/second). Retention: configure by time (x-max-age) or size (x-max-length-bytes). Stream protocol: dedicated binary protocol separate from AMQP for better performance. RabbitMQ 4.1+: SQL-like filter expressions for server-side filtering. Use cases: event sourcing, audit logs, time-series telemetry, log aggregation, message replay requirements. vs Traditional queues: streams for replay/audit, queues for task distribution. Essential for Kafka-like streaming patterns within RabbitMQ.

Streams vs Queues fundamental differences: (1) Consumption model: streams non-destructive (messages retained after read), queues destructive (deleted after ack). (2) Replay: streams support offset-based replay (read from any position), queues no replay (FIFO consumption only). (3) Multiple consumers: streams allow independent consumers reading from different offsets, queues distribute messages round-robin (each message to one consumer). (4) Retention: streams retain by time/size (x-max-age, x-max-length-bytes), queues ephemeral (messages deleted when consumed). (5) Performance: streams optimized for write throughput (millions/sec), queues optimized for low latency delivery. (6) Protocol: streams use dedicated stream protocol, queues use AMQP 0.9.1/1.0. (7) Use cases: streams for event sourcing/audit logs/replay, queues for task distribution/RPC/load balancing. Choose streams: replay requirements, multiple independent consumers, audit trails. Choose queues: one-time processing, task distribution, point-to-point messaging.

Virtual hosts (vhosts): logical isolation and multi-tenancy mechanism within single RabbitMQ instance. Each vhost is independent namespace containing separate exchanges, queues, bindings, users, permissions. Default vhost: '/' (forward slash). Create: rabbitmqctl add_vhost production. Benefits: (1) Resource isolation (queues in vhost A invisible to vhost B), (2) Security isolation (separate user permissions per vhost), (3) Multi-tenancy (multiple teams/applications on one broker), (4) Environment separation (dev/staging/production on same instance). Connection: specify vhost in AMQP URI (amqp://user:pass@host:5672/vhostname). Limitations: vhosts share same RabbitMQ node resources (RAM, CPU, disk), not for hard resource limits. Use cases: SaaS multi-tenancy, team isolation, environment separation. Essential for organized production deployments and cost-effective multi-tenant architectures.

Virtual host usage workflow: (1) Create vhost: rabbitmqctl add_vhost /production (use forward slash prefix). (2) Create user: rabbitmqctl add_user appuser password123. (3) Grant permissions: rabbitmqctl set_permissions -p /production appuser '.' '.' '.' (configure, write, read regex patterns). (4) Connect: amqp://appuser:password123@host:5672/production (URL-encode vhost name, '/' becomes %2F). Common naming: /dev, /staging, /prod or /tenant-a, /tenant-b for multi-tenancy. Management UI: vhost dropdown selector, create vhosts graphically. CLI operations: add -p /vhostname flag (rabbitmqctl list_queues -p /production). Permission patterns: configure (declare/delete resources), write (publish), read (consume). Use cases: environment isolation (dev/test/prod), multi-tenant SaaS (per-customer vhost), team separation (separate permissions). Best practices: least privilege (specific regex, not .), audit permissions regularly, use policies per vhost. Essential for security and organizational structure.

RabbitMQ vs Kafka key differences: RabbitMQ - Traditional message broker for complex routing and task distribution. Consumption: destructive (messages deleted after ack). Routing: 4 exchange types (direct, fanout, topic, headers) with flexible bindings. Protocols: AMQP 0.9.1, AMQP 1.0, MQTT, STOMP. Queue types: classic, quorum, streams (3.9+). Strengths: low latency (<10ms), complex routing patterns, RPC/request-reply, priority queues. **Kafka** - Distributed event streaming platform for high-throughput logs. Consumption: non-destructive (offset-based replay). Partitioning: topics split into partitions for parallelism. Retention: configurable (time/size). Strengths: massive throughput (millions/sec), long-term retention, stream processing, exactly-once semantics. **Choose RabbitMQ**: task queues, RPC, complex routing, low latency, traditional messaging, priority handling. **Choose Kafka**: event sourcing, log aggregation, stream processing, replay requirements, high throughput (>100k msg/sec). Note: RabbitMQ streams (3.9+) provide Kafka-like capabilities within RabbitMQ.