Message queue use cases in RabbitMQ - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Primary use case of message queues in distributed systems

Which of the following best describes the main purpose of using a message queue like RabbitMQ in a distributed system?

A To store large files and media content for web applications

B To enable asynchronous communication between services, decoupling producers and consumers

C To perform real-time data analytics on streaming data

D To replace databases for persistent data storage

💡 Hint

Think about how services communicate without waiting for each other.

Message queues like RabbitMQ allow services to send messages without waiting for the receiver to process them immediately, enabling asynchronous and decoupled communication.

❓ scaling

intermediate

Scaling consumers with RabbitMQ

If a system uses RabbitMQ to process tasks and the number of tasks suddenly increases, what is the best way to handle the increased load?

A Increase the size of the RabbitMQ server's disk space

B Switch to a synchronous request-response model

C Add more consumer instances to process messages in parallel

D Reduce the message TTL (time to live) to discard old messages faster

💡 Hint

Think about how to process more messages at the same time.

Adding more consumers allows the system to process messages concurrently, improving throughput and handling increased load effectively.

❓ tradeoff

advanced

Tradeoff between message durability and performance

What is a common tradeoff when configuring RabbitMQ for message durability?

A Enabling message durability increases latency but prevents message loss on broker failure

B Disabling message durability improves security but reduces throughput

C Disabling message durability guarantees message delivery order

D Enabling message durability decreases latency and increases throughput

💡 Hint

Consider what happens when the broker crashes and how durability affects speed.

Durable messages are saved to disk, which slows down processing but ensures messages are not lost if the broker crashes.

❓ Architecture

advanced

Designing a fault-tolerant task processing system with RabbitMQ

Which architectural pattern best ensures that tasks are not lost and are processed at least once using RabbitMQ?

A Use durable queues, persistent messages, and manual message acknowledgments

B Use transient queues with automatic message deletion after consumption

C Use non-persistent messages with auto-acknowledgment enabled

D Use a single consumer with no message acknowledgments

💡 Hint

Think about how to avoid losing messages even if the system crashes.

Durable queues and persistent messages ensure messages survive broker restarts, and manual acknowledgments confirm successful processing to avoid message loss.

❓ estimation

expert

Estimating RabbitMQ capacity for peak load

A system expects to receive 10,000 messages per second at peak. Each message is 1 KB in size. The RabbitMQ server has a network bandwidth of 1 Gbps and disk write speed of 100 MB/s. What is the main bottleneck when enabling message durability?

A Disk write speed is the bottleneck because 10,000 KB/s (approx 10 MB/s) is less than disk speed, so no bottleneck

B Network bandwidth is the bottleneck because 10,000 KB/s equals 80 Mbps, which is less than 1 Gbps

C Disk write speed is the bottleneck because 10,000 KB/s (approx 10 MB/s) is close to disk speed limit

D Neither network nor disk is a bottleneck because both exceed the required throughput

💡 Hint

Calculate the data rate and compare with bandwidth and disk speed.

10,000 messages * 1 KB = 10 MB/s, which is well below both 1 Gbps network (~125 MB/s) and 100 MB/s disk write speed, so no bottleneck.