Federation vs Shovel in RabbitMQ: Key Differences and Usage

In RabbitMQ, Federation connects brokers to replicate messages dynamically across networks, ideal for loosely coupled clusters. Shovel is a more controlled, configurable tool that moves messages between brokers or queues reliably, suited for guaranteed delivery and complex routing.

Quick Comparison

This table summarizes the main differences between RabbitMQ Federation and Shovel plugins.

Feature	Federation	Shovel
Purpose	Dynamic message replication between brokers	Reliable message transfer between brokers or queues
Setup Complexity	Simpler, uses upstream/downstream links	More configuration options, complex setup
Message Flow	Pulls messages from upstream brokers	Pushes messages to target brokers or queues
Use Case	Multi-datacenter, loosely coupled clusters	Guaranteed delivery, complex routing scenarios
Reliability	Best effort, may lose messages on failure	Retries and confirms for guaranteed delivery
Management	Managed via policies and plugins	Managed via configuration or API

Key Differences

Federation in RabbitMQ is designed to link multiple brokers by pulling messages from an upstream broker to a downstream broker. It works well for loosely connected clusters where brokers may be in different data centers or networks. Federation is easier to set up and uses policies to define which exchanges or queues to federate.

On the other hand, Shovel actively pushes messages from a source queue or exchange to a destination queue or exchange, often on a different broker. It is more configurable and reliable, supporting message acknowledgments and retries to ensure messages are not lost. Shovel is suitable for scenarios requiring guaranteed delivery and complex routing logic.

Federation is more about replicating messages dynamically with less overhead, while Shovel is a robust tool for controlled message movement with delivery guarantees. Federation may lose messages during network failures, whereas Shovel retries until success or failure is explicitly handled.

Federation Code Example

bash

rabbitmq-plugins enable rabbitmq_federation rabbitmq_federation_management
rabbitmqctl set_policy federate-me ".*" '{"federation-upstream-set":"all"}'

Output

The following plugins have been enabled:
rabbitmq_federation
rabbitmq_federation_management
Setting policy "federate-me" for pattern ".*" with federation upstream set "all"

Shovel Equivalent

json

{
  "component": "shovel",
  "name": "my-shovel",
  "value": {
    "src-uri": "amqp://",
    "src-queue": "source-queue",
    "dest-uri": "amqp://remote-broker",
    "dest-queue": "destination-queue",
    "ack-mode": "on-confirm",
    "reconnect-delay": 5
  }
}

Output

Shovel "my-shovel" configured to move messages from source-queue to destination-queue with confirmation and reconnect delay

When to Use Which

Choose Federation when you need simple, dynamic replication of messages across brokers in different locations with minimal setup and can tolerate occasional message loss during network issues.

Choose Shovel when you require guaranteed message delivery, complex routing, or need to move messages reliably between different RabbitMQ brokers or clusters with retry and confirmation support.

Key Takeaways

Federation pulls messages dynamically for easy multi-broker replication but may lose messages on failure.

Shovel pushes messages reliably with retries and acknowledgments for guaranteed delivery.

Use Federation for loosely coupled, multi-datacenter setups with simpler configuration.

Use Shovel for controlled, reliable message movement and complex routing needs.

Both plugins complement RabbitMQ's distributed messaging capabilities depending on reliability and complexity requirements.