Choosing a Queue by Starting with the Problem

Define the workload before comparing products

We began by studying the problem the queue needed to solve. A queue selected for strict message ordering may be different from one selected for very high throughput, simple background processing, broad protocol compatibility, or minimal operational effort.

This problem definition became the basis of the comparison. It prevented a well-known product from winning simply because it was popular.

Create a credible shortlist

We reviewed established open-source and commercial options, considering active maintenance, recent releases, reputation, available support, community adoption, and compatibility with the company's environment.

Three candidates were shortlisted for detailed analysis. Every candidate was then evaluated against the same criteria, including:

• Supported languages, frameworks, APIs, and protocols
• Delivery guarantees, message ordering, and duplicate handling
• Expected throughput, latency, and scaling model
• Durability, retry behaviour, and dead-letter handling
• Integration with the company's existing services
• Security, monitoring, and operational requirements
• Community or vendor support
• Licensing, hosting, and expected operating cost
• Release activity and long-term maintenance outlook

Published throughput figures were treated carefully. Vendor benchmarks are useful indicators, but they are not guarantees for a different workload. Where performance remained a deciding factor, the report recommended validating it with a representative proof of concept.

Make the evidence easy to inspect

The detailed findings were supported by links to the relevant official sources. This allowed reviewers to verify an answer, investigate a limitation, or repeat the analysis if a product changed later.

A one-page decision summary placed the three candidates side by side. Positive, conditional, and negative findings used clear labels and symbols as well as colour, so the meaning did not depend on red and green alone.

The report separated three things that are often mixed together:

1. Verified product facts
2. Our observations about the trade-offs
3. Our recommended option for the stated problem

This made it clear where evidence ended and professional judgment began.

Recommend without taking ownership away

We concluded the report with our preferred option and the reasons it best matched the defined workload. We also documented the conditions that could make another candidate more appropriate.

The engineering manager retained the final decision because that role owned the wider architecture, delivery risk, team capability, and operating budget.

The practical lesson is that a technology comparison should not produce a universal winner. It should reduce uncertainty around a specific decision. Define the problem, compare every candidate consistently, preserve the evidence, explain the trade-offs, and leave the accountable decision with the person who owns its consequences.