Bots revendedores: el año en que las colas dejaron de significar nada

Qué cambió: las colas como teatro

Antes, una cola significaba algo. Significaba: “Las solicitudes llegan más rápido de lo que podemos atender, así que serializaremos el acceso en un orden justo.”
En la web, ampliamos ese significado a “salas de espera virtuales”, que es una forma educada de decir:
movimos el cuello de botella a una página que podemos controlar.

El cambio no fue sutil. Las operaciones de los revendedores ahora tratan los sistemas de colas como otra API a ingeniería inversa.
No “se saltan la fila” con magia. Lo hacen con ingeniería: sesiones paralelas, navegadores sin cabeza con plugins de sigilo,
proxies residenciales, captchas ya resueltos, cookies calentadas y automatización que reintenta exactamente como lo haría un humano—excepto a escala 500×.

Mientras tanto, muchas empresas siguen diseñando colas como si los atacantes se unieran cortésmente a la misma fila. Ese es el modelo mental equivocado.
Tu cola es un límite de un sistema distribuido. Los atacantes:

• Adquirirán más “identidades” que usuarios reales (IPs, dispositivos, sesiones, instrumentos de pago).
• Explotarán desajustes de estado entre CDN, proveedor de cola, aplicación y servicio de inventario.
• Convertirán cada caso límite en tu lógica de equidad en un centro de ganancias.

Cuando escuches “la cola fue evitada”, tradúcelo a: “el token de la cola y la autorización de compra no estaban vinculados criptográficamente y operativamente.”
Si solo recuerdas una frase, que sea esa.

Broma #1: Una sala de espera virtual es como un portero de discoteca que revisa IDs y luego reparte pulseras hechas de papel mojado.

Hechos y contexto histórico que explican el presente

Esto no son trivialidades; son las migas de pan que condujeron al stack moderno de los revendedores.

1. Las guerras de bots en ticketing no son nuevas. La compra automatizada de entradas fue un problema generalizado mucho antes de que los “drops limitados de zapatillas” fueran un evento cultural.
2. Las salas de espera se hicieron populares tras colapsos en ventas flash de alto perfil. El objetivo original era la estabilidad (proteger el origen) más que la equidad.
3. Los CAPTCHA evolucionaron hacia una carrera armamentística. Lo que empezó como “prueba que eres humano” se convirtió en “prueba que no eres un objetivo rentable”, porque resolver CAPTCHA ahora se subcontrata o automatiza.
4. Las redes de proxies residenciales convirtieron en comoditizar los “usuarios únicos”. Los atacantes pueden comprar diversidad de IPs como compras instancias en la nube—por gigabyte.
5. Los navegadores sin cabeza se volvieron sigilosos. Señales de detección como flags de webdriver o huellas de canvas extrañas dejaron de ser fiables a medida que las herramientas maduraron.
6. Las señales del lado del cliente se volvieron fáciles de falsificar. Si tu anti-bot depende solo de comprobaciones JavaScript sin vinculaciones en el servidor, será reproducido.
7. Los proveedores de colas estandarizaron patrones—y los atacantes estandarizaron bypasses. Integraciones reutilizadas significan debilidades reutilizadas.
8. Los operadores de bots aprendieron a jugar todo el embudo. No solo presionan “añadir al carrito”. Pre-calientan sesiones, vigilan endpoints de inventario y explotan reservas y liberaciones.

Modelo de amenazas: contra qué te enfrentas realmente

La pila de un bot revendedor, en términos sencillos

Las operaciones modernas de revendedores parecen menos un script kiddie y más un pequeño equipo SRE con ética cuestionable.
Componentes típicos:

• Fábrica de identidades: miles de emails, números de teléfono, direcciones; a veces reales, a veces sintéticos.
• Fábrica de sesiones: navegadores lanzados en paralelo; tarros de cookies persistidos; tiempos y desplazamientos “humanos”.
• Diversidad de red: proxies residenciales rotativos; mezcla de ASN; geofencing para coincidir con la ubicación esperada del comprador.
• Diversidad de pago: múltiples tarjetas, múltiples monederos; a veces cuentas mule.
• Herramientas de cola: recolectores de tokens, lógica de reproducción, estrategias multi-pestaña y sincronización al momento de corte de la cola.
• Telemetría: grafican tus respuestas. Códigos de estado, latencia, cambios de inventario e incluso sutiles diferencias en HTML.

Qué significa “equidad” para ellos

La equidad no es un argumento moral. Es un algoritmo. Si la equidad de tu sistema depende de “una solicitud = una persona”,
ya perdiste, porque pueden manufacturar solicitudes.

Qué debes proteger

• Estabilidad del origen: tu aplicación no debe colapsar; la equidad no importa si el sitio está caído.
• Integridad de la autorización: la posición en la cola debe traducirse a un derecho limitado y verificable para intentar la compra.
• Corrección del inventario: las retenciones, liberaciones y decrementos finales deben ser coherentes bajo carga y reintentos.
• Confianza del usuario: la UI de la cola no puede prometer una equidad que en realidad no aplicas.

Una cita para pegar en un post-it:
Idea parafraseada — Werner Vogels: “Todo falla, todo el tiempo; construye sistemas que lo asuman y se recuperen rápidamente.”

Dónde fallan las colas en producción

1) Tu token de cola no es una autorización

Muchas implementaciones tratan la cola como un “suavizador de tráfico” y luego permiten que cualquiera que llegue al origen proceda.
Eso está al revés. Necesitas una autorización verificable por el servidor que sobreviva reintentos pero que no pueda ser acuñada o reproducida ampliamente.

Modo de fallo: el token de la cola es solo una cookie verificada por la lógica del edge; el atacante la reproduce desde muchas sesiones.
O no está ligada a nada significativo (dispositivo, rango IP, clave de sesión, TTL corto, nonce de un solo uso).

2) Filtras estado por canales laterales

Los atacantes no necesitan adivinar. Observan.
HTML distinto, cadenas de redirección diferentes, cabeceras de caché distintas, deltas en tiempos de respuesta—todo revela si un token es “bueno”,
si existe inventario o si una retención tuvo éxito.

3) Las retenciones de inventario se convierten en un ataque de denegación de inventario

“Reservar en el carrito por 10 minutos” suena amable hasta que un bot puede reservar 10.000 carritos.
Si no ligas las retenciones a autorizaciones escasas y no las expiras/recuperas agresivamente, has inventado una nueva clase de outage:
el sitio está arriba, pero nada es comprable.

4) Tu WAF bloquea las cosas equivocadas

Reglas estáticas (bloquear headless, bloquear IPs de datacenter) atrapan a los bots del año pasado y a falsos positivos del presente.
Los mejores atacantes se parecen a tus clientes más entusiastas—hasta que no.

5) Tu “anti-bot” rompe más el embudo que los bots

El fingerprinting y los desafíos demasiado agresivos pueden hundir la conversión legítima y empujar a humanos a bucles infinitos.
Si tus mitigaciones causan más pérdida de ingresos que el scalping, te has auto-infligido un DDoS.

6) Una cola es un sistema distribuido: fallos de consistencia son inevitables

El CDN ve un mundo. El proveedor de colas ve otro. El origen ve un tercero. El servicio de inventario ve el cuarto.
Si no has mapeado exactamente cómo ocurren las transiciones de estado, estás depurando por intuición.

Guía de diagnóstico rápido

Cuando un drop sale mal, no tienes tiempo para filosofía. Necesitas encontrar el cuello de botella rápido y decidir qué sacrificar:
equidad, disponibilidad o ingresos. Aquí está el orden que suele funcionar en incidentes reales.

Primero: ¿es estabilidad o integridad?

• Si los orígenes están agotándose (5xx, latencia elevada): trátalo como incidente de fiabilidad. Descarga carga, protege la base de datos, reduce funcionalidades.
• Si el sitio está estable pero los humanos no pueden comprar (colapso de conversión, inventario desaparecido): trátalo como incidente de integridad. Enfócate en fuga de autorizaciones, retenciones y rutas de automatización.

Segundo: localiza el punto de estrangulamiento

• Tasas de desafío/bloqueo del CDN/WAF
• Tasa de aceptación de la cola vs paso a origen
• Códigos de error de la API de checkout (patrones 429/403/409/422)
• Tasas de creación/expiración de retenciones de inventario

Tercero: prueba o descarta la reproducción de tokens

• Mismo token de cola visto desde múltiples IPs/ASNs
• Mismo ID de sesión usado con muchos UA/pistas de dispositivo distintas
• Alta concurrencia por cuenta/instrumento de pago

Cuarto: elige un modo de mitigación

• Modo disponibilidad: límites de tasa estrictos, páginas estáticas, deshabilitar endpoints no esenciales, estrechar el embudo.
• Modo integridad: endurecer autorizaciones (TTL corto, uso único), ligar retenciones a autorizaciones, aumentar fricción en la compra, no en la navegación.
• Modo recuperación: invalidar tokens filtrados, purgar retenciones, reiniciar la cola con un mensaje transparente.

Tareas operativas: comandos, salidas, decisiones

Esto no son “ejecuta esto y siéntete productivo”. Cada comando responde a una pregunta que te harán durante un drop:
qué está roto, quién lo hace y qué hacemos después.

Task 1: Confirmar si la cola realmente está limitando el acceso al origen

cr0x@server:~$ curl -I -s https://shop.example.com/limited-drop | sed -n '1,20p'
HTTP/2 302
date: Tue, 22 Jan 2026 18:03:11 GMT
location: https://queue.example.com/wait?c=shop&t=abc123
cache-control: no-store
server: cdn-edge

Qué significa: Un 302 hacia la cola sugiere que el edge está haciendo gating para esa ruta.
Decisión: Prueba múltiples rutas (endpoints API, endpoints de la app móvil, hostnames alternativos). Los atacantes lo harán.

Task 2: Comprobar si las APIs “protegidas” son accesibles sin contexto de cola

cr0x@server:~$ curl -s -o /dev/null -w "%{http_code}\n" https://shop.example.com/api/checkout/session
200

Qué significa: Si un endpoint crítico devuelve 200 sin prueba de cola, tu cola es mayormente decorativa.
Decisión: Añade enforcement en el servidor: requiere un token de autorización para la creación de checkout/session.

Task 3: Detectar reproducción de tokens en muchos IPs en logs de acceso

cr0x@server:~$ zgrep -h 'queue_token=' /var/log/nginx/access.log* | awk -F'queue_token=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
842 QTK.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
611 QTK.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
199 QTK.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Qué significa: El mismo token apareciendo cientos de veces es una señal de reproducción.
Decisión: Rota claves de firmado y aplica semánticas de uso único o baja reutilización (jti + caché en servidor de tokens usados).

Task 4: Correlacionar un token con múltiples IPs clientes

cr0x@server:~$ zgrep -h 'QTK.eyJhbGci' /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head
120 203.0.113.18
118 198.51.100.77
116 192.0.2.44

Qué significa: Un token usado desde muchas IPs: o bien NAT a escala (posible) o reproducción por bots (probable).
Decisión: Liga autorizaciones a una clave de sesión estable y aplica límites de deriva (IP / ASN / JA3 con tolerancia).

Task 5: Confirmar efectividad del rate limiting en el edge

cr0x@server:~$ curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://shop.example.com/api/inventory/sku/PS5
200 0.042

Qué significa: Un 200 rápido para un endpoint de alto valor sugiere que está cacheado o desprotegido.
Decisión: Si debe existir, hazlo de baja resolución (sin conteos exactos), añade jitter, requiere autorización o cachea con respuestas normalizadas.

Task 6: Detectar acumulación de retenciones de inventario desde Redis

cr0x@server:~$ redis-cli -h redis01 -p 6379 INFO stats | egrep 'expired_keys|evicted_keys'
expired_keys:12890
evicted_keys:0

Qué significa: Altos expired_keys durante un drop normalmente indican una tormenta de retenciones o sesiones de corta duración.
Decisión: Si las retenciones están expirando en masa, acorta TTL de retenciones, limita retenciones por autorización/cuenta y libera rápidamente en fallos de pago.

Task 7: Medir cardinalidad de retenciones por patrón de clave (muestreo)

cr0x@server:~$ redis-cli -h redis01 --scan --pattern 'hold:*' | head
hold:sku:PS5:session:6f3b1a
hold:sku:PS5:session:9c2dd0
hold:sku:PS5:session:aa91e4

Qué significa: Esto confirma que existen retenciones y muestra la forma de la clave.
Decisión: Si el patrón es solo basado en sesión, considera vincular a autorización + cuenta para prevenir acaparamiento anónimo.

Task 8: Verificar contención en la base de datos (Postgres)

cr0x@server:~$ psql -h pg01 -U ops -d shop -c "select wait_event_type, wait_event, count(*) from pg_stat_activity where state='active' group by 1,2 order by 3 desc limit 10;"
 wait_event_type |  wait_event   | count
-----------------+---------------+-------
 Lock            | transactionid  |    34
 Lock            | tuple          |    19
 Client          | ClientRead     |     8

Qué significa: Esperas por locks sugieren que los decrementos/retenciones de inventario están serializándose de forma ineficiente.
Decisión: Pasa a primitivas atómicas de inventario (contadores de fila única, SKIP LOCKED, o servicio de inventario dedicado) y reduce la contención de filas calientes.

Task 9: Encontrar los endpoints más calientes en logs de NGINX

cr0x@server:~$ awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
182344 /api/inventory/sku/PS5
99112 /api/cart/add
60441 /api/checkout/session
22101 /limited-drop

Qué significa: Los endpoints de inventario y carrito están recibiendo palizas.
Decisión: Aplica controles por endpoint: límites de tasa más estrictos, comprobaciones de autorización y caching/normalización para consultas de inventario.

Task 10: Confirmar comportamiento de caché CDN para páginas de cola y drop

cr0x@server:~$ curl -I -s https://shop.example.com/limited-drop | egrep 'cache-control|age|via|cf-cache-status|x-cache'
cache-control: no-store
via: 1.1 cdn-edge
x-cache: MISS

Qué significa: no-store y MISS: cada solicitud llega a infraestructura más profunda.
Decisión: Cachea agresivamente páginas de shell estáticas; mantén la lógica personalizada/por autorización en endpoints pequeños y rápidos.

Task 11: Revisar tasas de challenge/deny del WAF (ejemplo vía logs locales)

cr0x@server:~$ zgrep -h 'waf_action=' /var/log/nginx/access.log* | awk -F'waf_action=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr
19422 challenge
8121 allow
905 deny

Qué significa: Alto volumen de “challenge” puede significar que los bots están consumiendo desafíos—o que los humanos sufren.
Decisión: Si la conversión cae, ajusta desafíos para que se activen más tarde (en checkout) y usa scoring de riesgo en lugar de fricción por defecto.

Task 12: Validar comportamiento de idempotencia en checkout (prevenir amplificación por reintentos de bots)

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://shop.example.com/api/checkout/submit \
  -H "Idempotency-Key: 2d2a7a52-1b7b-4a6c-a9c0-9a3b3c0e6b25" \
  -H "Content-Type: application/json" \
  --data '{"cart_id":"c_123","payment_method":"pm_abc"}' | sed -n '1,20p'
HTTP/2 201
date: Tue, 22 Jan 2026 18:06:02 GMT
content-type: application/json
x-idempotency-replayed: false

Qué significa: El servidor reconoce idempotencia e indica que esto no es una reproducción.
Decisión: Repite la misma petición; si crea múltiples órdenes, estás financiando tormentas de reintentos y comportamientos de doble gasto extraños.

Task 13: Repetir la petición idempotente y verificar manejo de reproducción

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://shop.example.com/api/checkout/submit \
  -H "Idempotency-Key: 2d2a7a52-1b7b-4a6c-a9c0-9a3b3c0e6b25" \
  -H "Content-Type: application/json" \
  --data '{"cart_id":"c_123","payment_method":"pm_abc"}' | sed -n '1,20p'
HTTP/2 200
date: Tue, 22 Jan 2026 18:06:08 GMT
content-type: application/json
x-idempotency-replayed: true

Qué significa: Comportamiento correcto de reproducción: la segunda llamada devuelve el resultado original.
Decisión: Exige claves de idempotencia para endpoints que finalizan la compra; limita la tasa sin romper reintentos legítimos.

Task 14: Comprobar desfase de reloj (los bugs de TTL y tokens aman el skew)

cr0x@server:~$ timedatectl status | sed -n '1,12p'
Local time: Tue 2026-01-22 18:06:30 UTC
Universal time: Tue 2026-01-22 18:06:30 UTC
RTC time: Tue 2026-01-22 18:06:29
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Qué significa: Si los relojes se desincronizan, las autorizaciones de corta vida fallan aleatoriamente, lo que parece como “la cola está rota”.
Decisión: Arregla NTP antes de reducir TTL de tokens; de lo contrario castigarás primero a usuarios reales.

Task 15: Inspeccionar distribución de huellas TLS (JA3) desde logs del balanceador (formato de ejemplo)

cr0x@server:~$ awk '{print $NF}' /var/log/haproxy/haproxy.log | sort | uniq -c | sort -nr | head
78211 771,4866-4867-49195-49196-52393,0-11-10-35-16-5-13-18-23-65281,29-23-24,0
11992 771,4865-4866-4867-49195,0-11-10-35-16-5-13-18-23-65281,29-23-24,0

Qué significa: Un pequeño número de huellas TLS dominando puede indicar clientes de automatización.
Decisión: No bloquees solo por JA3; úsalo como señal de riesgo combinada con comportamiento (picos, velocidad de checkout, reutilización de tokens).

Tres micro-historias corporativas desde el frente

Micro-historia 1: El incidente causado por una suposición equivocada

Una marca de consumo desplegó una sala de espera antes de un drop limitado. El liderazgo estaba orgulloso: había una página de cola, un temporizador
y una línea tranquilizadora sobre “primero en llegar, primero en ser atendido”. El equipo asumió que el token del proveedor de cola era efectivamente un ticket.

No lo era. El token de la cola se comprobaba en la capa CDN para páginas HTML, pero los endpoints de la app móvil estaban en un hostname distinto
y no pasaban por el mismo conjunto de reglas. Un operador de bots encontró la forma de la API en la app, se saltó la sala de espera por completo
y llamó directamente a “create checkout session”.

El outage no fue un crash; fue una falla reputacional. Humanos sentados en la sala de espera mientras bots compraban por la puerta lateral.
Soporte al cliente recibió capturas de pantalla. Las redes sociales hicieron lo suyo. Mientras tanto, SRE miraba dashboards verdes porque la latencia estaba bien.

La solución fue casi aburrida: unificar el gating entre hostnames y exigir una claim de autorización en el origen para cualquier llamada que cambie estado.
También escribieron una prueba de contrato: “Sin autorización, checkout/session debe ser 403.” Se ejecutó en CI y desde un canario en prod.

Micro-historia 2: La optimización que salió mal

Otra compañía optimizó su endpoint de inventario para reducir carga de base de datos. Cachearon “stock restante” en el edge por 5 segundos.
El dashboard se veía genial: menos llamadas al origen, menor CPU, finanzas contentas.

A los bots les encantó. Esa caché convirtió el endpoint de inventario en un oráculo de timing limpio. Los atacantes observaban las respuestas cacheadas,
coordinaban ráfagas de compra y aprendieron exactamente cuándo se reponía stock por expiración de retenciones. Los humanos, mientras tanto, seguían viendo
estados “en stock” obsoletos y pulsaban “añadir al carrito” provocando conflictos 409.

El equipo intentó arreglarlo aumentando el TTL de caché. Eso redujo aún más la carga al origen e hizo el oráculo más fuerte.
La “optimización” creó un nuevo plano de control para atacantes: predecible, barato y globalmente distribuido.

Lo deshicieron y reemplazaron el endpoint con una respuesta normalizada: “disponible / tal vez / agotado”, más una sugerencia de backoff.
Los conteos exactos se retiraron de superficies públicas. Internamente mantuvieron precisión. Externamente dejaron de alimentar a los bots.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un gran minorista ejecutaba “días de juego” trimestrales para drops. Nada glamuroso. La gente se quejaba de que era repetitivo.
Practicaban todo: activación de cola, verificación de autorizaciones, retenciones de inventario, reintentos de pago y rollback.

En un ensayo descubrieron un bug sutil: los tokens de autorización los validaba un servicio usando UTC y otro usando hora local.
Solo unos segundos de diferencia, pero suficientes para crear 403 intermitentes justo en el checkout cuando los tokens tenían TTL corto.

Arreglarlo fue mundano: estandarizar en UTC, mejorar monitorización NTP y añadir una pequeña ventana de tolerancia para claims exp/nbf.
También añadieron monitores sintéticos que recorrían todo el embudo con inventario de prueba.

Durante el evento real, el tráfico de bots se disparó, pero el sistema se mantuvo predecible. Los humanos pasaron. El volumen de soporte se mantuvo normal.
La compañía no “ganó” contra los bots para siempre; evitó el caos autoinfligido. Esa suele ser la meta alcanzable.

Patrones de diseño que aún funcionan (y qué evitar)

Vincula la posición en la cola a una autorización verificable por el servidor

Una UI de cola no es enforcement. El enforcement vive en el origen, preferiblemente en el primer endpoint que cambia estado.
Diseña un token de autorización que sea:

• Firmado (HMAC o asimétrico), con TTL corto.
• Escopado al acción y SKU/categoría (no des “checkout de todo” si el drop es un SKU).
• Vinculado a sesión/cuenta de forma que puedas validar en el servidor.
• Resistente a reproducción con jti y una pequeña caché en servidor de tokens usados para la finalización de compra.

Evita la trampa: “No podemos almacenar estado para tokens.” No necesitas estado para cada petición. Lo necesitas donde cambia dinero
y donde la reproducción de un token puede acuñar múltiples órdenes.

Haz que “añadir al carrito” sea barato, pero que “reservar inventario” sea escaso

La gente spamea añadir al carrito cuando está ansiosa. Los bots lo hacen porque funciona. No confundas ambos.
Deja que añadir al carrito sea una facilidad de UI, pero requiere autorización para convertir carrito en retención.

• Limita retenciones por autorización/cuenta/instrumento de pago.
• Expira retenciones agresivamente y recupéralas de forma determinista.
• No crees retenciones para sesiones anónimas si puedes evitarlo.

Normaliza señales públicas; guarda precisión internamente

Si un endpoint revela stock exacto, tiempo de corte de la cola o errores de validación con alta especificidad, los atacantes lo instrumentarán.
Pueden iterar más rápido que tu on-call.

Las respuestas públicas deben ser intencionalmente aburridas. Internamente aún necesitas precisión para ops y finanzas.
El error es darle a los atacantes la misma telemetría que usas.

Prefiere scoring de riesgo y aumento de fricción en el momento correcto

Si desafías a todos en la puerta, ralentizas a los humanos y das tiempo a los bots para cultivar soluciones.
Si desafías en el momento de consumir un recurso escaso (retención o envío de checkout), obtienes apalancamiento.

Aquí también puedes justificar pedir pruebas más fuertes: inicio de sesión en la cuenta, email/teléfono verificado, verificación de pago
o vinculación de dispositivo. No puedes exigir eso para navegar sin incendiar tu tasa de conversión.

Usa claves de idempotencia, donde importe

Los bots reintentan agresivamente. Los humanos reintentan accidentalmente. Tu sistema debe tratar los reintentos como normales, no como error.
La idempotencia no es un “agradable de tener”; es una forma de prevenir amplificación cuando el tráfico se vuelve raro.

Transparencia operativa vence promesas falsas

No digas a los usuarios “justo” si no puedes aplicarlo. Di lo que puedes garantizar:
“Limitamos compras por cliente”, “podemos cancelar órdenes sospechosas”, “tu lugar en la fila otorga una ventana limitada de checkout.”
Sé específico. Afirmaciones vagas de equidad se convierten en capturas de pantalla después.

Broma #2: Lo único más rápido que un bot revendedor es una reunión post-incidente que empieza con “Pero el proveedor dijo…”.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: La cola parece sana, pero el inventario se agota al instante

• Causa raíz: El gating de la cola solo se aplica a rutas HTML; las APIs están abiertas o en hostnames alternativos.
• Solución: Aplica la autorización en el origen para todos los endpoints que cambian estado. Añade tests automáticos que aseguren 403 sin autorización.

2) Síntoma: Humanos atrapados en bucles infinitos de desafíos

• Causa raíz: WAF/fingerprints sobreajustados; señales cliente inestables; desfase de reloj causando fallos de token.
• Solución: Reduce fricción en la navegación; lleva el step-up a retención/checkout; añade tolerancia de token y alarmas NTP; monitoriza tasa de éxito de desafíos por clase de dispositivo.

3) Síntoma: Retenciones masivas en carritos, “agotado” mientras luego reaparece stock

• Causa raíz: El sistema de retenciones puede ser spameado sin autorización escasa; TTL demasiado largo; retenciones no reclamadas tras fallo de pago.
• Solución: Vincula retenciones a autorización; limita retenciones por cuenta/dispositivo; acorta TTL; libera inmediatamente en autorización de pago fallida.

4) Síntoma: Picos de 409/422 en checkout, pero la CPU está bien

• Causa raíz: Contención de fila caliente en la BD de inventario; concurrencia optimista sin backoff; tormentas de reintento.
• Solución: Usa primitivas atómicas de inventario; añade backoff guiado por el servidor; aplica idempotencia; limita la tasa de submit de checkout por separado.

5) Síntoma: Aumentan bloqueos del WAF, cae la conversión, los bots siguen ganando

• Causa raíz: Reglas ajustadas a firmas de bots antiguas; atacantes usan IPs residenciales y navegadores reales.
• Solución: Cambia a detección basada en comportamiento (velocidad, reutilización de tokens, patrones multi-cuenta). Añade límites de compra y pipeline de revisión/cancelación post-compra.

6) Síntoma: Reportes de “bypass de la cola” se correlacionan con usuarios de la app móvil

• Causa raíz: Endpoints de la app no integrados con comprobaciones de cola/autoridad; URL base en el cliente evita reglas del CDN.
• Solución: Exige las mismas claims de autorización para APIs de la app; unifica hostnames/routing; rota secretos embebidos en clientes y asume que son públicos.

7) Síntoma: Los bots parecen saber exactamente cuándo activas el drop

• Causa raíz: Señales de timing predecibles: invalidaciones de caché, sitemap/product JSON, SKUs precargados o flags de staging expuestos.
• Solución: Escalona activación internamente; evita endpoints públicos “coming soon” con estado preciso; normaliza respuestas; usa feature flags que no sean observables externamente.

Listas de verificación / plan paso a paso

Checklist pre-drop (la semana antes)

1. Mapea el embudo. Cada hostname y endpoint desde la landing hasta la confirmación de pedido. Si no puedes dibujarlo, no puedes defenderlo.
2. Clasifica endpoints. Público/anónimo, autenticado, que cambia estado, sensible a inventario, que finaliza pago.
3. Aplica autorización en origen. No solo en CDN. Empieza en “crear retención” y “crear sesión de checkout”.
4. Verifica idempotencia. Submit de checkout y autorización de pago deben ser idempotentes con clave forzada por servidor.
5. Establece límites de compra. Por cuenta, por instrumento de pago, por dirección de envío (con manejo cuidadoso de falsos positivos).
6. Decide la política de cancelación. Si vas a cancelar órdenes sospechosas, crea el workflow antes del día de lanzamiento.
7. Ejecuta un game day. Simula tráfico tipo bot, intentos de reproducción de tokens y acaparamiento de retenciones. Arregla lo que falle.
8. Instrumenta métricas correctas. Tasa de paso de la cola, fallos de validación de autorizaciones, creación/expiración de retenciones, éxito de checkout, bucles de desafío.

Checklist día del drop (horas antes)

1. Confirma salud de NTP y relojes. Tokens de TTL corto + skew = dolor aleatorio.
2. Calienta cachés deliberadamente. Cachea contenido estático; mantén autorizaciones dinámicas sin caché.
3. Configura límites de tasa seguros. Baseline por IP y por sesión, con límites de emergencia más estrictos listos.
4. Activa toggles de “modo integridad”. Aumenta desafíos en retención/checkout; revisa reutilización de tokens; reduce precisión de señales de inventario.
5. Prepara comunicaciones. Un banner en la página de estado y una macro de soporte que no prometa equidad imposible.

Plan de incidente en vivo (cuando va mal)

1. Protege el origen primero. Si suben 5xx, descarga carga. Una cola justa para un sitio caído es performance art.
2. Valida el gating. Prueba llamadas directas a APIs; confirma que las autorizaciones son requeridas.
3. Revisa reproducción de tokens. Muestreo de logs para tokens repetidos entre IPs; restringe con jti de un solo uso en checkout.
4. Revisa retenciones. Si explotan, limita y acorta TTL; purga patrones abusivos.
5. Contrae el embudo. Temporalmente deshabilita endpoints de bajo valor (polling de inventario) y refuerza pasos de compra.
6. Decide reinicio. Si la integridad es irrecuperable (tokens ampliamente filtrados), reinicia la cola y sé honesto al respecto.

Checklist post-drop (dentro de 48 horas)

1. Reconciliación de inventario. Confirma que retenciones/liberaciones/decrementos coinciden con pedidos.
2. Revisa órdenes sospechosas. Aplica la política de cancelación consistentemente; documenta criterios.
3. Escribe el informe de incidente. Incluye qué hicieron los bots, qué señales funcionaron y qué falló.
4. Añade tests de regresión. Una prueba por cada ruta de bypass descubierta. Las pruebas aburridas son cómo conservas victorias.
5. Retune controles. Reduce falsos positivos para la próxima vez; registra las excepciones que tuviste que hacer.

Preguntas frecuentes

¿Las colas todavía ayudan en algo?

Sí—para la estabilidad. Reducen la carga al origen y suavizan picos. Pero las colas no garantizan equidad a menos que víncules el paso por la cola
a una autorización verificable y la apliques en el origen.

¿Por qué no simplemente bloquear IPs de datacenter?

Porque los operadores serios usan proxies residenciales y navegadores reales. Bloquear datacenters atrapa algo de ruido pero no detendrá a los compradores
que importan, y puede perjudicar redes corporativas legítimas.

¿Un CAPTCHA es suficiente?

No. CAPTCHA es fricción, no identidad. Puede ser resuelto por humanos por contrato o burlado con mejor automatización.
Úsalo como control de step-up, no como la base de tu modelo de equidad.

¿Cuál es el bypass de cola más común?

APIs sin protección. Los equipos protegen la landing pero olvidan el endpoint de checkout/session, las APIs móviles o un host legacy que evita las reglas de la cola.

¿Cómo prevenimos el acaparamiento de carritos sin castigar a usuarios lentos?

Haz que las retenciones sean escasas y acotadas: requiere autorización para crear una retención, limita retenciones por usuario/instrumento de pago y acorta TTL con
una extensión solo para checkouts que progresan activamente.

¿Deberíamos exponer conteos exactos de inventario?

¿Públicamente? Normalmente no. Los conteos exactos crean un oráculo que los bots explotan. Internamente, conserva precisión. Externamente, normaliza a estados gruesos
y añade sugerencias de backoff para reducir polling.

¿El fingerprinting de dispositivo puede resolver esto?

Ayuda, pero es frágil y sensible a la privacidad. Trata los fingerprints como señales de riesgo, no como identidad absoluta.
Espera spoofing y falsos positivos en dispositivos compartidos y herramientas de privacidad.

¿Qué significa realmente “vincular la autorización a la sesión”?

Significa que el token de autorización solo debe ser válido cuando se presenta junto con una clave de sesión o cookie relacionada emitida durante
el paso por la cola, y debe estar scopiado (SKU/acción) y ser de corta duración.

Si no podemos detener completamente los bots—¿qué meta es realista?

Mantén el sitio arriba, permite que los humanos compren y haz la automatización costosa. Luego añade enforcement post-compra:
límites de compra, revisión de órdenes sospechosas y políticas de cancelación/reembolso consistentes.

¿Es seguro cancelar órdenes sospechosas?

Es operacionalmente complejo pero a menudo necesario. Si lo haces, define criterios claros, mantiene trazabilidad de auditoría y un workflow de soporte.
Cancelaciones aleatorias crean furia de clientes y riesgo legal.

Conclusión: pasos prácticos siguientes

Los bots revendedores no “rompieron las colas” porque sean listos. Rompieron las colas porque muchas implementaciones de cola nunca fueron diseñadas
para ser fronteras de seguridad. Fueron diseñadas para evitar que tu base de datos se derritiera. Problema distinto.

Pasos siguientes que realmente mueven la aguja:

1. Audita tu embudo para hostnames y APIs no protegidos. Trátalo como un pen test, porque los atacantes ya lo hicieron.
2. Implementa autorizaciones aplicadas en origen con scope y TTL estrictos, y resistencia a reproducción en la finalización de compra.
3. Vincula retenciones de inventario a autorizaciones escasas y capéalas. Una retención es un recurso; ponle precio adecuadamente.
4. Normaliza señales públicas para que los bots no usen tu sitio como su panel de control.
5. Practica el evento con game days y tests de regresión. Es aburrido. También funciona.

La verdad incómoda: no eliminarás a los revendedores. Pero puedes hacer que las colas vuelvan a significar algo—transformándolas de teatro a
enforcement, y gestionando el sistema como si el adversario ya estuviera en la sala. Porque lo está.