RabbitMQ en producción: colas resilientes para sistemas backend — Volkanic

Cuando el equipo de Sidetours decidió mover la comunicación entre servicios de llamadas HTTP síncronas a mensajería asíncrona, la primera versión que desplegamos era técnicamente funcional pero frágil. Los mensajes se perdían si el consumidor fallaba, no había visibilidad sobre el estado de las colas, y un bug en producción tardó horas en diagnosticarse.

Este artículo documenta los patrones que aprendimos —a menudo por error— para operar RabbitMQ con criterio de producción real.

Por qué asincronía

Antes de hablar de RabbitMQ, la pregunta real es cuándo tiene sentido la mensajería asíncrona frente a una llamada HTTP directa.

La respuesta corta: cuando el resultado de una operación no necesita estar disponible inmediatamente en la misma request.

Ejemplos concretos donde las colas ganaron claramente:

Envío de emails y notificaciones después de una reserva
Sincronización de disponibilidad con proveedores externos (tolerancia a latencia alta)
Generación de informes y PDFs en background
Propagación de eventos entre servicios (disponibilidad → precio → confirmación)

Lo que no se debe mover a colas: operaciones que el usuario necesita ver confirmadas inmediatamente (login, pago, creación de reserva).

Anatomía de una configuración correcta

Exchanges y routing

El error más común en equipos que empiezan con RabbitMQ es publicar directamente a colas. El patrón correcto es publicar a un exchange y dejar que el routing key decida a qué cola llega el mensaje.

# ❌ Publicar directamente a una cola
channel.basic_publish(exchange='', routing_key='notifications', body=message)

# ✅ Publicar a un exchange con routing key semántico
channel.basic_publish(
    exchange='booking.events',
    routing_key='booking.confirmed',
    body=message,
    properties=pika.BasicProperties(
        delivery_mode=2,  # persistent
        content_type='application/json',
        message_id=str(uuid.uuid4()),
        timestamp=int(time.time()),
    )
)

Para sistemas de eventos de dominio, un topic exchange ofrece el routing más flexible:

booking.confirmed  → notification-service, reporting-service
booking.cancelled  → notification-service, refund-service
payment.failed     → alert-service

Dead Letter Queues: el seguro de vida

Toda cola de producción debe tener una DLQ (Dead Letter Queue) configurada. Cuando un mensaje no puede procesarse (excepción, formato inválido, recurso no disponible), RabbitMQ lo redirige a la DLQ en lugar de perderlo.

channel.queue_declare(
    queue='booking-notifications',
    durable=True,
    arguments={
        'x-dead-letter-exchange': 'booking.dlx',
        'x-dead-letter-routing-key': 'booking-notifications.dlq',
        'x-message-ttl': 86400000,  # 24h TTL para mensajes normales
    }
)

# Declarar también la DLQ
channel.queue_declare(
    queue='booking-notifications.dlq',
    durable=True,
)

La DLQ no es solo un cubo de basura: es donde diagnosticas qué está fallando en producción. Siempre tenla monitorizada.

Acknowledgements manuales: la diferencia entre robusto y frágil

Por defecto, RabbitMQ considera que un mensaje fue procesado en el momento de entregarlo al consumidor. Si el proceso muere a mitad del procesamiento, el mensaje se pierde.

La solución es usar acknowledgements manuales y confirmar solo cuando el procesamiento ha terminado con éxito:

def process_message(ch, method, properties, body):
    try:
        data = json.loads(body)
        send_confirmation_email(data)
        
        # Solo confirmamos si todo fue bien
        ch.basic_ack(delivery_tag=method.delivery_tag)
        
    except TemporaryError as e:
        # Error transitorio: devolver a la cola para reintentar
        logger.warning(f"Requeuing message: {e}")
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=True)
        
    except PermanentError as e:
        # Error permanente: rechazar sin reintentar (va a DLQ)
        logger.error(f"Rejecting message permanently: {e}")
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)

channel.basic_qos(prefetch_count=10)  # Limitar mensajes en vuelo por consumidor
channel.basic_consume(queue='booking-notifications', on_message_callback=process_message)

La distinción entre errores transitorios (red, base de datos temporalmente no disponible) y errores permanentes (formato inválido, recurso inexistente) es crítica para no crear bucles infinitos de reintentos.

Backoff exponencial con reintentos

Para errores transitorios, el patrón más robusto es reintentar con backoff exponencial en lugar de reintentar inmediatamente:

# Tabla de colas de reintento con TTL creciente
RETRY_QUEUES = [
    {'queue': 'notifications.retry.1m',  'ttl': 60_000},     # 1 minuto
    {'queue': 'notifications.retry.5m',  'ttl': 300_000},    # 5 minutos
    {'queue': 'notifications.retry.30m', 'ttl': 1_800_000},  # 30 minutos
]

def requeue_with_backoff(ch, method, properties, body):
    retry_count = (properties.headers or {}).get('x-retry-count', 0)
    
    if retry_count >= len(RETRY_QUEUES):
        # Agotamos reintentos: a la DLQ
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)
        return
    
    retry_queue = RETRY_QUEUES[retry_count]['queue']
    new_headers = {**(properties.headers or {}), 'x-retry-count': retry_count + 1}
    
    ch.basic_publish(
        exchange='',
        routing_key=retry_queue,
        body=body,
        properties=pika.BasicProperties(headers=new_headers, delivery_mode=2),
    )
    ch.basic_ack(delivery_tag=method.delivery_tag)

Cada cola de reintento tiene un TTL configurado como su DLX apunta de vuelta a la cola original. El mensaje “duerme” el tiempo configurado y vuelve a intentarse automáticamente.

Monitorización: no operes RabbitMQ a ciegas

Las métricas que debes tener monitorizadas en producción:

# Usando la API de management de RabbitMQ
GET /api/queues

# Métricas clave por cola:
# - messages_ready: mensajes esperando consumidor
# - messages_unacknowledged: en procesamiento
# - message_stats.deliver_get.rate: throughput
# - consumers: número de consumidores activos

Alertas mínimas que deberías tener:

messages_ready > 1000 en cualquier cola de producción
consumers == 0 en cualquier cola crítica
DLQ con mensajes (siempre debería estar vacía en operación normal)
Conexiones caídas

En Sidetours usamos CloudWatch con métricas exportadas vía el exporter de Prometheus de RabbitMQ. Un dashboard simple con estas cuatro métricas nos salvó varias veces de problemas silenciosos.

Idempotencia: el superpoder de las colas

Dado que RabbitMQ puede entregar un mensaje más de una vez en caso de fallo del consumidor, los consumidores deben ser idempotentes: procesar el mismo mensaje dos veces debe tener el mismo resultado que procesarlo una.

def send_confirmation_email(booking_id: str):
    # Verificar si ya se procesó este mensaje
    if email_already_sent(booking_id):
        logger.info(f"Email already sent for booking {booking_id}, skipping")
        return
    
    send_email(booking_id)
    mark_email_as_sent(booking_id)

La implementación más simple: una tabla en base de datos con el message_id de los mensajes ya procesados, con un índice único. Si el insert falla por constraint violation, el mensaje ya fue procesado.

Conclusión

RabbitMQ es una herramienta extraordinariamente potente, pero requiere configuración cuidadosa para ser fiable en producción. Los tres principios que más impacto tuvieron en nuestra operación:

Siempre acknowledgements manuales — nunca confiar en la entrega automática
Siempre DLQ configurada — nada se pierde, todo es investigable
Consumidores idempotentes — el sistema funciona aunque un mensaje se entregue dos veces

La fiabilidad de un sistema de mensajería no se mide en condiciones normales, sino en el comportamiento ante fallos. Con estos patrones, nuestras colas sobrevivieron deploys a mitad de procesamiento, caídas de red y bugs en consumidores sin perder un solo mensaje.