What size should I use for my queue

Devs brawl over queue size: go big or expose the bottleneck

TLDR: The post says queues don’t speed things up; they buffer bursts and should be sized by acceptable wait times. Comments split between “make it huge for peace” and “keep it small to expose problems,” with SRE war stories, “just add Kafka” jokes, and debates over backpressure making it a must-read for reliability stakes.

A humble post asking “What size should I use for my queue?” ignited a full-on internet brawl. The author argues queues don’t make your system faster; they’re just buffers to handle traffic bursts and timing hiccups. The kicker: size your queue by how long you’re willing to make people wait (latency), and when it fills up, choose your poison—push back on the sender or drop messages. Sounds reasonable… until the comments exploded.

On one side, the Big Buffer Brigade: “RAM is cheap, peace and quiet is priceless.” Their vibe: crank it up until the pager stops screaming. Opposite them, the Bounded-and-Honest Squad says oversized queues just hide pain—keep them small, trigger alarms fast, and fix the slow part. SREs (the on-call firefighters) piled in with war stories of “infinite queues” turning outages into archaeology digs. Product folks cried, “We can’t lose messages,” while platform engineers shot back, “You already are—just slower.” Cue memes: “Just add Kafka,” “Queues are computer todo lists,” “Schrödinger’s queue: empty in dev, infinite in prod.” Bonus nerd fight: Little’s Law vs “Little’s Lie,” and backpressure shoutouts via Reactive Streams. Drama level: spicy; takeaway: your queue is a mirror—do you want flattery or the truth?

Key Points

  • Queues primarily buffer burst traffic and reconcile timing differences; they do not increase average throughput.
  • If the sustained arrival rate exceeds processing capacity, increasing queue size will not prevent eventual overload.
  • Burst handling depends on queue size; a system can handle steady rates but may overflow on concentrated bursts.
  • For batch systems (e.g., CSV rows), maximum queue size can be bounded by batch size, potentially reduced by concurrent processing.
  • Real-time systems require queue sizing based on latency limits; strategies include dropping messages or applying back pressure when full.

Hottest takes

"If your queue fixes throughput, you built a trash compactor" — CynicalOps
"Bigger queue. RAM is cheaper than pager fatigue" — ShipItSam
"Drop early, alert loudly, or enjoy a 3am zombie backlog" — PagerEater
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.