The built-in NestJS RabbitMQ transport does not expose exchange configuration directly. Use @golevelup/nestjs-rabbitmq for advanced exchange patterns. Define exchanges in RabbitMQModule.forRoot(), bind handlers to routing key patterns with @RabbitSubscribe(), and publish with AmqpConnection.publish().

Topic exchange with @golevelup/nestjs-rabbitmq

Topic exchange routing key rules:

1
- (asterisk) — matches exactly one word in the routing key.
2
(hash) — matches zero or more words; orders.# matches everything under orders.
3
Topic exchanges are the most flexible pattern — prefer them over direct or fanout for complex routing.
4
@golevelup/nestjs-rabbitmq provides a more complete AMQP integration than the built-in NestJS transport.
5
Fanout exchanges broadcast to all bound queues regardless of routing key — use for broadcasting events.

Difficulty: 6/10

Topics: Topic exchange, Routing keys, NestJS microservices

Scenario Questions

0-2 years experience

1
Suppose you need to send order events to different services based on the event type (e.g., order.created, order.cancelled). How would you set up a RabbitMQ topic exchange in a NestJS microservice to route these messages to the appropriate queues?
2
If you accidentally configure the exchange type as 'direct' instead of 'topic', what behavior would you observe when publishing a message with routing key 'order.created'?
3
Can you show a minimal NestJS module that declares a queue bound to a topic exchange with a wildcard routing key like 'order.*'?

2-5 years experience

1
Your team added a new routing key pattern 'order.payment.*' but messages with that key are not reaching the intended queue. Walk me through how you would debug the issue in NestJS and RabbitMQ.
2
When scaling the NestJS service horizontally, you notice duplicate processing of the same message. Which part of the topic exchange or queue configuration might be causing this, and how would you fix it?
3
Explain the trade‑offs between using a single topic exchange with many bindings versus multiple exchanges for different domains in a NestJS application.

5-8 years experience

1
Design a high‑throughput event pipeline using NestJS and RabbitMQ topic exchanges that must guarantee at‑least‑once delivery across several microservices. What patterns would you employ to handle failures, back‑pressure, and ordering?
2
How would you modify your NestJS topic exchange setup to support dynamic addition of new routing keys at runtime without redeploying services?
3
Discuss the performance implications of using many wildcard bindings (e.g., '#') in a topic exchange. How would you mitigate potential routing overhead in a large‑scale NestJS deployment?

8+ years experience

1
Your organization is migrating from a monolithic RabbitMQ setup with topic exchanges to a multi‑region, multi‑cluster architecture. What architectural changes would you propose for the NestJS services to maintain consistent routing semantics and minimize latency?
2
Consider a scenario where different teams own overlapping routing key namespaces (e.g., 'user.' and 'user.profile.'). How would you establish governance and versioning for topic exchanges in NestJS to avoid conflicts over the long term?
3
If you needed to replace RabbitMQ with a cloud‑native event bus (e.g., Google Pub/Sub) while preserving existing topic‑based routing logic in NestJS, what migration strategy would you adopt to ensure minimal disruption?

Follow-up Questions

❓What happens if a message is published with a routing key that matches no queue binding?
❓How would you monitor and troubleshoot routing mismatches in production?
❓Can you describe how you would ensure ordering guarantees when multiple consumers share a queue?

How do you implement a RabbitMQ topic exchange for routing messages to multiple queues based on routing keys in NestJS?

(hash) — matches zero or more words; orders.# matches everything under orders.

Scenario Questions

Follow-up Questions