Designing a Topology

A topology that grows cleanly

A clear topology makes a system understandable. Common conventions: one exchange per domain or bounded context, owned by the publishing team (orders, payments, catalogue), usually of type topic; routing keys that describe the event in a fixed shape, such as <entity>.<event>.<region> (order.placed.in); one queue per consuming service and purpose, named after the consumer (billing.orders, email.orders), so each service owns its queue, prefetch and scaling; and a dead-letter exchange and parking-lot queue per consumer. Publishers never declare consumers' queues; consumers declare (or request) their own queues and bindings. Keep definitions in version control: RabbitMQ can import and export a JSON definitions file, and tools like Terraform providers or the Kubernetes Messaging Topology Operator manage exchanges, queues, bindings, users and policies declaratively. Apply cross-cutting settings such as queue type, DLX, TTL and length limits through policies rather than hardcoding them in every client.

Exchange per domain, queue per consumer

Each publishing domain owns an exchange; each consuming service owns its queue and dead-letter queue.

A definitions file excerpt

Topology as code, importable at startup or through the management API.

{
  "vhosts": [{ "name": "shop" }],
  "exchanges": [
    { "name": "orders", "vhost": "shop", "type": "topic", "durable": true },
    { "name": "billing.dlx", "vhost": "shop", "type": "fanout", "durable": true }
  ],
  "queues": [
    { "name": "billing.orders", "vhost": "shop", "durable": true,
      "arguments": { "x-queue-type": "quorum" } },
    { "name": "billing.orders.dead", "vhost": "shop", "durable": true,
      "arguments": { "x-queue-type": "quorum" } }
  ],
  "bindings": [
    { "source": "orders", "vhost": "shop", "destination": "billing.orders",
      "destination_type": "queue", "routing_key": "order.placed.*" },
    { "source": "billing.dlx", "vhost": "shop", "destination": "billing.orders.dead",
      "destination_type": "queue", "routing_key": "" }
  ],
  "policies": [
    { "vhost": "shop", "name": "billing-dlx", "pattern": "^billing\\.orders$",
      "apply-to": "queues", "definition": { "dead-letter-exchange": "billing.dlx", "delivery-limit": 5 } }
  ]
}

Name for the reader at 3 a.m.

During an incident, billing.orders tells an on-call engineer who consumes the queue and what it holds. queue_7 or q-main tells them nothing.

त्वरित जाँच: In a domain-oriented topology, who usually owns a consumer queue such as billing.orders?

• The billing team, which consumes from it
• The orders team, because it publishes the messages
• Nobody; queues are anonymous
• The database team