---
title: "message queues | Skills We Assign For | Azendo"
description: "Message queues in production systems — delivery guarantees, ordering and the failure modes to design for, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/message-queues/"
---

[Skills](https://azendo.co/skills/) APIs and integration 

# message queues.

A message queue decouples a producer from a consumer by putting durable storage between them, so the sender does not wait for the receiver and a slow or failed consumer does not propagate failure upstream. It converts a synchronous dependency into an asynchronous one, with delivery guarantees to reason about.

## Where message queues fits on a long engagement.

Queues are usually introduced to fix a latency or coupling problem and succeed at it immediately. The difficulty arrives later, in the shape of questions the synchronous version never asked: what happens when the same message is delivered twice, what happens when messages arrive out of order, and where does a message go when it fails for the fiftieth time.

Most production queue incidents trace to a missing dead-letter path or to consumers that are not idempotent. Both are cheap to design in at the start and expensive to retrofit once there is a backlog nobody can safely replay. The guarantee a broker actually offers — usually at-least-once, not exactly-once — is the fact to design against rather than hope around.

## What an assigned team does with message queues.

An asynchronous system fails in ways a synchronous one does not, and the failures are quieter. A queue that is slowly growing is invisible on a dashboard nobody built, which is why queue depth and consumer lag belong in the same conversation as the feature that introduced them.

Where that monitoring is the actual gap, the capacity that closes it is platform capacity rather than application capacity, assigned under [devops as a service](https://azendo.co/services/cloud-and-devops/) on the same agreement.

## What we use message queues for.

* Work that must not block a user request Email, exports and third-party calls moved off the request path so a slow provider does not become a slow page.
* Absorbing bursts without over-provisioning A queue as a buffer, so a traffic spike becomes a longer processing window rather than a set of errors.
* Making retries safe Idempotent consumers and a dead-letter path, so redelivery is routine rather than an incident.

## How message queues capacity is assigned.

Queue work is assigned inside the discipline that owns the producing and consuming services. Where the constraint is the broker and its monitoring rather than the application, platform capacity is scoped alongside it.

## Roles we assign message queues for

* [Backend Developer Software development](https://azendo.co/services/software-development/backend-developer/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in apis and integration

* [REST — skill we assign for](https://azendo.co/skills/rest/)
* [GraphQL — skill we assign for](https://azendo.co/skills/graphql/)
* [gRPC — skill we assign for](https://azendo.co/skills/grpc/)
* [webhooks — skill we assign for](https://azendo.co/skills/webhooks/)
* [Kafka — skill we assign for](https://azendo.co/skills/kafka/)
* [API design — skill we assign for](https://azendo.co/skills/api-design/)
* [FastAPI — skill we assign for](https://azendo.co/skills/fastapi/)
* [RabbitMQ — skill we assign for](https://azendo.co/skills/rabbitmq/)

## Tell us what your roadmap needs message queues for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)