Should you force a message queue when system concurrency is low?

For systems whose daily concurrency has stayed below a few hundred QPS for years, most scenarios do not require introducing a message queue. Direct synchronous calls, database optimistic locking plus caching, or simple local asynchronous tasks can usually handle the load. The criterion is not how small the current average traffic is, but whether the peak in the next six months to a year can break the limits of existing dependencies. If the peak falls far short of the bottleneck, the complexity introduced by a message queue far outweighs its benefits.

Why a perfectly fine project gets recommended a message queue

In projects, several common situations lead to this: first, an architect or technical lead feels their resume is incomplete without MQ, so they want to find a business scenario to practice; second, sales or product casually mentions "the volume will be huge later," and the technical side starts assuming large-scale concurrency; third, during project acceptance, reviewers believe that without MQ it cannot be called a "high-availability architecture." None of these reasons are based on the real traffic pattern of the business.

Based on project delivery practices in 2026, systems' reliance on message queues is no longer as aggressive as in previous years. Many internal management systems and back-office applications may not even process ten thousand messages a day. Forcing MQ simply shifts the problem from "how to handle messages" to "how to ensure messages are not lost, duplicated, or out of order." On delivery sites, clients often get stuck on: "Why do approval messages occasionally delay by ten minutes in the expensive MQ cluster I bought?" — a problem that simply does not exist in traditional synchronous calls.

• Real business peak traffic: First look at the maximum requests per second in interface logs, not the average.
• Weak points of existing dependencies: Is the database connection pool sufficient? Are third-party API responses stable? Is peak shaving and valley filling needed?
• Team's operational capability: Is there someone who can handle backlog, dead letters, and consumer idempotency?

When is a message queue truly needed

The core value of a message queue is decoupling, peak shaving, and asynchrony, but it is cost-effective only when multiple conditions are met simultaneously. The first condition is inconsistent processing speeds between upstream and downstream. For example, a frontend request needs to write to the database, update the cache, and send notifications; doing this synchronously would drag the interface to multi-second latency, yet the business does not need these results returned in real time. The second condition is a pronounced spike in traffic. For instance, the request volume in the first five minutes of a campaign is 50 times the normal level, and the database cannot scale up instantly.

In one project, I built an e-commerce social system whose push service peaked at tens of thousands of messages per day, but the business allowed up to 5 minutes of delay, making MQ peak shaving appropriate. But if those two conditions are absent, and the only reason is "to make the code structure more elegant," you can fully use API callbacks, event tables, and scheduled tasks as alternatives.

• Scenarios suitable for MQ: Cross-system asynchronous notifications, large-scale data import/export, and flash-sale high-concurrency instantaneous writes.
• Unsuitable scenarios: Simple CRUD writes, transaction-critical paths with high real-time requirements, and teams with fewer than 5 people and no dedicated operations staff.

Three-step verification: Deciding whether your system should adopt MQ

On delivery sites, I generally follow three steps to verify, which can help the team turn "it feels necessary" into "a data-supported conclusion." Step one: print the interface access logs for the last three months, calculate the 95th and 99th percentiles of requests per second, and also look at how long a single request spends on the database and third-party APIs. Step two: load-test the current solution, simulate traffic at three times the peak, and see whether the database connection pool or thread pool fills up first, or whether the CPU hits the bottleneck first. Step three: check business tolerance. Ask the product manager: "If a notification is delayed by 5 minutes, will users complain?" If they will, MQ does not solve the root problem; you need stronger real-time processing capability.

The value of this approach is turning "architecture selection" into "verifiable engineering judgment." Each step has clear cautions: in step one, distinguish average from peak. Many systems have an average QPS of only 20, but an hourly flash-sale spike can reach 300; looking only at the average is misleading. In step two, actually load-test; don't just run small traffic in a test environment. In step three, obtain written confirmation from the business side, otherwise disagreements will arise after launch.

1. Check peak traffic: Take the maximum requests per minute in the last 3 months and multiply by a safety factor of 1.5.
2. Check existing dependencies: Does the database connection pool get exhausted first, or do third-party APIs time out first?
3. Check business tolerance: Can the business accept a 5-minute delay and 0.1% message loss?

If you decide to use one, which message queue is reliable?

When selecting, there are two main categories: one is RabbitMQ and similar tools focused on routing and flexible forwarding; the other is Kafka or Pulsar, which focuses on high-throughput sequential reads and writes. Based on project delivery practices in 2026, ordinary enterprise internal systems prefer RabbitMQ because it is simple to deploy, has an intuitive management console, and its consumer failure retry strategy is mature. Kafka is better suited for large-scale sequential read/write scenarios like log collection and behavioral stream processing, but it has higher learning and operational costs.

For comparison dimensions, I recommend putting "team familiarity" ahead of "performance metrics." I've seen more than one project choose Kafka after hearing about its high throughput, only to find that no one could manage message backlog in production, and they finally fell back to RabbitMQ. The experience range is: a single RabbitMQ node supporting thousands of messages per second is sufficient for common business; a single Kafka node can reach more than 100,000 per second, but daily systems basically don't need that.

• RabbitMQ: Flexible routing, UI-friendly, suitable for business messages; based on experience, a single node supports thousands of TPS without issue.
• Kafka: High throughput, replayable, suitable for logs and stream processing; however, partition and consumer group configuration is complex, and the learning curve is high.
• Pulsar: Multi-tenancy and storage-compute separation are highlights, but community resources are relatively scarce; don't choose it lightly if the team is unfamiliar with it.

FAQ

What to do if messages are lost in the message queue?

First confirm whether the loss occurs at the producer, broker, or consumer side, then handle it accordingly: enable the confirm mechanism on the producer side, disable auto-ack on the consumer side, store messages in the database with status markers, and periodically check and compensate manually.

Do you have to implement distributed transactions when using MQ?

Not necessarily. Most businesses can solve it with a local message table plus retries. Only when strong consistency is required across multiple microservices should you consider Seata or MQ transaction messages; ordinary systems don't need the extra complexity.

Which should you choose: RabbitMQ or Kafka?

Prefer RabbitMQ unless you confirm your business is log collection or requires message replay. Based on experience, Kafka's operations and learning costs take 2-3 times more time, which may not be cost-effective for the team.

How to detect delays caused by message backlog in advance?

Monitor the queue backlog count and set alerts. Also prepare for rapid scaling at the consumer side, such as reserving consumer thread pools or container replicas, and rehearse a load test before going live.

Applicable scenarios and boundaries

This judgment method suits internal systems maintained by small and medium-sized teams, B-side management backends, and businesses with daily request volumes ranging from tens of thousands to millions. In these scenarios, not using MQ initially, and instead using synchronous calls plus scheduled tasks, often has advantages in cost, maintainability, and troubleshooting.

The unsuitable cases are also clear: if the system must handle hundreds of thousands of QPS in the first month after launch, or if the business chain has multiple cross-team service dependencies that must be decoupled, then MQ is not an option but a necessity. In addition, if the team hasn't even set up basic log monitoring, first build that foundation; don't introduce new middleware.

Spend half a day counting peaks, load-testing existing modules, and confirming latency tolerance with the product team before deciding whether to adopt MQ. If you decide to introduce it, start with RabbitMQ and set up monitoring and alerts. If you decide not to, document the premise of this decision to avoid someone else raising the same question six months later. Once this boundary condition is clear, architecture choices won't wobble.