Queue Architectures That Survive Black Friday

A queue is a promise: this work happens reliably, eventually. Most systems keep that promise beautifully at normal load and abandon it entirely during the traffic spike that actually matters. Here's what separates pipelines that bend from pipelines that break.

Separate the critical path

Not all jobs are equal. Password resets and payment confirmations must never wait behind PDF generation. Split queues by business priority early — separate workers, separate Redis instances if volume demands — because retrofitting priority into a single shared queue under pressure is misery.

• critical: payments, auth emails — dedicated workers, alert on depth > 100
• default: user-triggered work — scales horizontally, minutes of tolerance
• bulk: exports, re-indexing — capped concurrency, hours of tolerance

Backpressure is a feature

An unbounded intake turns overload into collapse: every job retries simultaneously, each retry costs more than the last. Rate limiting middleware on external API calls, ShouldBeUnique to deduplicate fan-out storms, and honest retry budgets with exponential backoff keep the system doing useful work instead of thrashing.

<pre><code class="language-php">public function retryUntil(): CarbonInterface
{
    return now()-&gt;addHours(6);
}

public function backoff(): array
{
    return [30, 300, 900, 3600];
}</code></pre>

Measure what users feel

Queue depth lies — a deep but fast-draining queue is healthy, a shallow-but-stuck one is not. Wait time is the metric users experience: timestamp at dispatch, measure at processing. Alert on wait-time percentiles, not depth alone, and rehearse failure scenarios before the day they happen for real.

The pre-flight checklist

• retry_after comfortably exceeds the slowest job timeout
• Failed-job monitoring wired to the on-call channel
• Load-tested at 3× forecast peak — not 1×, not "probably fine"
• Runbooks for the three failures you consider most likely

Boring queues survive exciting days. Build for the spike you can predict, instrument for the ones you can't, and let the architecture absorb the drama so your team doesn't have to.