How does RabbitMQ federation and shovel work for multi-datacenter setups?

For multi-datacenter RabbitMQ deployments, two plugins handle cross-cluster messaging. Federation: logically links exchanges or queues across separate RabbitMQ clusters. An upstream exchange/queue feeds a downstream one via a federation link. Messages are pulled from upstream only when a downstream consumer needs them (demand-based). Benefits: works across WANs with high latency; the downstream cluster is independent (different policies, topologies); federation automatically handles network failures and reconnects. Use case: global publish, local consume — publish events to a central cluster, regional clusters subscribe and consume locally. Shovel: reliably moves messages from a source queue (local or remote) to a destination exchange/queue (local or remote). Unlike federation (pull-based), shovel actively moves every message. Better for ETL-like patterns where all messages must be transferred. Use cases: migrating between clusters, cross-DC data synchronization, legacy system integration. Cluster spanning: unlike Erlang clusters (tight coupling, same Erlang cookie, low latency required), federation and shovel work between independent clusters with network partitions and high latency.