All quizzesMedium
Redis, RabbitMQ & More — Series 3
Preview — 3 of 10 questions
What does the topic exchange decide?
javascript
order.created → exchange "orders" (topic) → bound queues
billing.queue binding key "order.*"
analytics.queue binding key "#"
shipping.queue binding key "order.shipped"AWhich consumer within a queue receives the message
BThe order in which queues receive the message
CWhich queues a published message is copied into, by matching the routing key against each binding pattern — so one publication reaches billing and analytics but not shipping, and adding a new consumer means adding a binding rather than changing the producer
DWhether the message is persisted to disk
Is the queue's durability enough for messages to survive a restart?
javascript
options: { queue: 'orders', queueOptions: { durable: true } }ANo — the queue must be durable and each message published as persistent; a durable queue survives with its bindings but an in-memory message in it does not, so both halves are required
BYes; a durable queue implies persistent messages
CNo — durability applies only to the exchange, not the queue
DYes, provided at least one consumer is connected
What does this arrangement achieve?
javascript
main.queue --nack(requeue: false)--> retry.queue (message-ttl: 30s, DLX: main.exchange)AIt retries the message immediately, which requeueing would delay
BIt discards the message after 30 seconds
CIt duplicates the message into two queues for parallel processing
DA delayed retry: the rejected message lands in a queue whose only job is to hold it for 30 seconds, after which its TTL expires and the dead-letter exchange routes it back to the main queue — giving a transient failure time to clear without spinning on it
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.