Amazon SQS estrena colas justas: el inquilino que inunda la cola ya no bloquea al resto
El servicio reparte el trabajo por grupos en lugar de por orden de llegada. Un cliente con 200.000 mensajes de golpe pasa al final y deja de arrastrar a los demás.
Amazon SQS ya distingue quién está inundando la cola. Desde julio de 2025 el servicio admite fair queues, un modo que reparte el trabajo entre inquilinos en lugar de atender estrictamente por orden de llegada. Si un cliente suelta 200.000 mensajes a las nueve de la mañana, sus mensajes se van al final y los de los otros siguen saliendo.
El problema que resuelve es el de siempre en un SaaS multi-inquilino: una sola cola para todos, porque montar una cola por cliente sale caro en operación. SQS cobra por petición, no por cola, así que 400 colas no cuestan más dinero, pero sí obligan a vigilar y hacer long polling sobre 400 colas casi siempre vacías. Mientras tanto, una cola estándar no mira quién envía: bajo acumulación, los consumidores engullen lo que tienen delante y gana quien más manda. El tiempo de espera de los clientes pequeños sube por tráfico que no es suyo.
Cómo se marca a un inquilino como ruidoso
SQS vigila el reparto de mensajes en vuelo. Un grupo se marca cuando acumula más del 10% de los mensajes en curso y tiene al menos 30 propios, y también cuando su cuota reciente de tiempo de proceso de los consumidores pasa del 10%. Esa segunda señal es la que pilla al cliente con pocos mensajes pero lentos. AWS avisa de que ambos números son aproximados, así que no sirve montar una prueba de carga esperando que el interruptor salte justo en el mensaje 30.
Un inquilino vuelve a la normalidad cuando vacía su acumulación o tras cinco minutos seguidos sin nada en vuelo. Si hay varios marcados a la vez, se atiende antes al que menos mensajes tiene en curso. El marcado no limita ni descarta nada: el cliente ruidoso ocupa el hueco que nadie más está usando.
Para activarlo basta con enviar un identificador de grupo al publicar, sin cambiar el tipo de cola ni tocar el consumidor. Eso sí, ese identificador tiene que ser algo con sentido -un ID de cliente o un tipo de petición-, nunca un ID por mensaje. La detección necesita 30 mensajes en vuelo por grupo, así que los identificadores demasiado granulares fallan en silencio. Y conviene instrumentar todos los productores a la vez: cualquier mensaje sin identificador cuenta como inquilino único, y un despliegue a medias llena SQS de miles de "inquilinos" de un solo mensaje que estropean las métricas.
Hay una trampa conocida: en una cola estándar ese identificador es solo una etiqueta. No da orden FIFO, aunque se llame igual que la propiedad de las colas FIFO. Los mensajes del mismo grupo siguen ejecutándose en paralelo, que es justo lo que se busca aquí.
Lo que cuesta y cuándo no vale la pena
No es gratis. Cualquier envío, recepción, borrado o cambio de visibilidad en el que al menos un mensaje lleve identificador de grupo se factura a tarifa de cola justa, encima de la tarifa estándar: del orden de 0,10 dólares por millón de peticiones en las regiones de Estados Unidos. Ojo con el "al menos uno": un lote de diez mensajes donde solo uno lleve identificador convierte toda la petición en petición de cola justa.
La telemetría incluye cinco métricas, entre ellas el número de grupos ruidosos y las variantes de mensajes en colas tranquilas. Comparar los mensajes visibles totales con los visibles en colas tranquilas enseña el mecanismo entero: durante un pico la primera línea se dispara y la segunda se queda plana. Para saber quién grita hace falta algo más: Contributor Insights ordena los inquilinos sin disparar la factura de métricas, pero construye ese ranking desde los logs, así que el consumidor tiene que registrar el identificador de grupo por su cuenta.
El propio AWS admite que hay motivos para no activarlo. Si la cola casi nunca acumula retraso, un pico de un inquilino no molesta a nadie. Si la flota de consumidores no es lo bastante ancha, la detección no llega a dispararse: la cuenta de mensajes en vuelo es concurrencia por tamaño de lote, y con dos o tres consumidores no se activa nunca. Y si a nadie en el producto le importa cuánto espera un trabajo, se paga un recargo por una propiedad que el usuario no va a notar. Compensa cuando hay mucho volumen, varios inquilinos y una latencia prometida por contrato.
Para verlo antes de fiarse, hay un repositorio de ejemplo con generador de carga y panel de CloudWatch, desplegable con CDK, y la documentación de SQS detalla las dos señales de marcado y los umbrales. Antes de probarlo, dimensiona bien la flota: es el error que más gente comete y el que lleva a concluir que la función está rota.
