Microservice Antipatterns: The Queue Explosion
For simplicity, let&#x27;s take RMQ<p>&gt;    Multiplying the load on message brokers, often 2-5x, requiring extensive and costly scale out of the messaging system<p>Scaling it out is no problem. kubectl apply -f statefulset.yaml  replicas=5 — done.<p>Also, message brokers almost never come under load because they are primarily IO bound, not CPU bound. If your broker comes under heavy CPU usage, you&#x27;re almost certainly doing something wrong.<p>&gt;    No easy flow-control, fast services can produce and consume messages quickly enough to cause side effects for the slow services that are the bottlenecks and dictate overall system performance. This can cause large swings in performance as queues fill up.<p>In a RPC based architecture flow control would be even worse, cascade up to the caller and cause timeouts and unbounded ephemeral queues that end up looking like a hung system. Worse even, the thundering herd problem will make you unable to get back up.<p>&gt;    Increased latency for end-to-end processing because of repeated round trips to the messaging broker, which must persist messages to disk each time<p>No, RMQ does not necessarily persist the message each time; you can get a publisher confirm back if all receivers have claimed the message.<p>Furthermore, while send-then-ACK latency can be up to the disk latency, you&#x27;re by no means limited to sending one message at a time.<p>&gt;    Increased difficulty isolating performance issues to an individual service vs the messaging brokers vs side-effects from other services impacting the messaging brokers<p>You almost never have performance issues affecting the brokers.<p>Suppose you do; then it&#x27;s most often because you&#x27;ve let your queues grow too long. Where would you be in a HTTP world? You&#x27;d be having an outage.<p>---<p>&gt; HTTP-based services (REST, gRPC, etc) offer low latency and high throughput compared to queues. They also have strictly lower resource requirements (network, disk, compute, memory) than a message queue solution.<p>No, not strictly lower; I can imagine a scenario where you have &gt;80% utilisation on your HTTP server on averge; now you&#x27;ll have growing ephemeral TCP request queues once in a while; then you have to bump the node stats. Consider the alternative; a node that has no latency requirement; it can be utilised to a higher degree; 90-100%. Always at 100%? Then, scale out based on queue size, then scale down again.