Rate limit, colas y antispam para formularios y bots

Rate limit, colas y antispam son tres capas de protección - sin ellas, los formularios y los bots de Telegram/Discord se convierten rápido en canal de spam, flood y DoS. Un CAPTCHA no basta: hace falta limitar frecuencia, procesar en asíncrono y filtrar por contenido y reputación. Abajo - cómo montar un esquema práctico para sitios y bots sin complejidad de más.

• Rate limit - cuántas peticiones se permiten por ventana de tiempo desde una IP, cuenta o token
• Cola - búfer entre aceptar la solicitud y el trabajo pesado (email, CRM, LLM, webhook)
• Antispam - honeypot, CAPTCHA, heurísticas, blocklists y revisión de contenido
• Regla - primero cortes la frecuencia y proceses en asíncrono; luego endureces los filtros
• Objetivo - conservar leads reales y no tumbar el servicio bajo un botnet
• Por qué le importa al negocio - menos spam en el CRM y el correo, facturas más bajas de SMS/LLM/API, ventas solo ve leads reales

Por qué atacan primero formularios y bots

Un endpoint público es una puerta sin llave. Los bots de spam buscan /contact, /api/lead y webhooks del bot, y envían miles de mensajes: phishing, spam SEO, credential stuffing, fuerza bruta de cupones. Sin límites suben las facturas de email/SMS/LLM, el CRM se llena de basura y los leads reales se ahogan en ruido.

Síntomas típicos:

1. Pico de POST al formulario con cero conversiones de venta
2. Textos idénticos desde IPs distintas - o basura única desde un mismo rango
3. Colas de email o webhooks chocan con límites del proveedor
4. El bot del mensajero responde más lento o cae por timeout

Rate limit: qué limitar y cómo

El rate limiting responde: «¿cuántas veces en N segundos se puede tocar este endpoint?». La clave del límite importa.

Ventanas prácticas:

• Formulario de leads: 3-5 envíos correctos por IP cada 10 minutos, más un tope duro a fallos (validación, CAPTCHA fallido)
• Login / OTP: aparte y más estricto - si no, fuerza bruta
• Comandos de bot: 1 respuesta pesada (generación, búsqueda) por usuario cada pocos segundos; comandos ligeros - más suave
• Techo global en proceso o worker - protege picos aunque las claves difieran

Al superar: HTTP 429 con Retry-After; en el bot - un «espere N segundos» corto, sin revelar umbrales internos. Registre los disparos: muestran si el límite es demasiado blando o demasiado duro.

Colas: por qué separar recepción y procesamiento

El formulario no debe escribir en el CRM, generar un PDF y llamar a una API externa de forma síncrona. Una cola (Redis, RabbitMQ, SQS, Celery, BullMQ) toma la tarea tras la validación y responde rápido: «solicitud aceptada».

Qué aporta la cola:

• Suavizado de picos - el spam o una campaña no tumba los procesos web
• Reintento ante fallos - retry con backoff en lugar de perder el lead
• Prioridades - pedidos pagados por encima de «descargar PDF»
• Aislamiento - workers de LLM/email escalan aparte del front

Flujo del formulario:

1. CSRF / origin, honeypot, validación básica de campos
2. Rate limit
3. Guardar el lead en BD con estado queued
4. Push a la cola
5. HTTP 200/202 al usuario
6. Worker: scoring antispam → CRM / email / notificación

Igual en bots: acepte rápido el update de Telegram; respuestas pesadas (RAG, imagen, parsing) van a la cola. Si no, long polling / webhook acumula latencia.

Antispam: capas, no una casilla

Un reCAPTCHA no cierra el tema. Construya defensa en profundidad.

1. Filtros baratos en la entrada

• Campo honeypot (oculto para personas, rellenado por bots)
• Tiempo mínimo de cumplimentación (demasiado rápido = bot)
• Comprobación de Referer / Origin y token CSRF
• Límite de tamaño del body y del número de adjuntos

2. CAPTCHA y challenges

Muestre el challenge por señal, no siempre: tras N intentos, IP sospechosa o score alto. CAPTCHA permanente hiere la conversión; puntual casi no.

3. Contenido y reputación

• Blocklists de dominios/URL en el texto
• Detección de plantillas repetidas y spam agnóstico al idioma
• Comprobación de email (MX, dominios desechables)
• En bots: filtro de enlaces, stop words, límite de media

4. Señales de comportamiento

Historial: cuántos envíos de este dispositivo acabaron en compra o chat útil. Una IP nueva con docenas de «buy SEO» por minuto - a cuarentena o revisión manual, no directo al CRM del comercial.

Cómo unir las tres capas

Orden recomendado en producción:

1. Validación y antispam barato (honeypot, tamaño, CSRF)
2. Rate limit por IP + id de usuario/chat
3. Respuesta rápida al cliente / mensajero
4. Cola con tope de jobs concurrentes por worker
5. Antispam pesado e integraciones en el worker (scoring, CRM, email)
6. Alertas ante picos de 429 y crecimiento de jobs rechazados

Así no gasta CPU ni dinero de proveedores en peticiones que el límite ya debía cortar.

Checklist de implantación

• [ ] Formulario y bot tienen límites distintos según el riesgo
• [ ] Hay circuit breaker global para email/SMS/LLM salientes
• [ ] 429 y mensajes del bot son claros, pero no enseñan a evadir
• [ ] La cola tiene DLQ (dead letter) y monitor de longitud
• [ ] Los leads sospechosos van a cuarentena, no a borrado silencioso
• [ ] Los logs de rate limit y spam-score se pueden revisar por IP/hash, endpoint y score sin acceso completo a datos personales (nombres, emails, teléfonos, texto de las solicitudes)
• [ ] Prueba de carga: qué pasa a 100 RPS en /contact

Cuándo aún no conviene complicarse

No todos los proyectos necesitan todo el esquema de golpe:

• Sitio estático sin formularios ni bots - no hay nada que proteger, no hacen falta límites
• Menos de 10-20 leads al día y sin APIs/LLM externas - basta con captcha y un límite a nivel de hosting/CDN (Cloudflare, Nginx); una cola aparte todavía no se amortiza
• MVP temprano - primero valide que el mercado quiere el producto; añada antispam y cola a medida que crecen el tráfico y los primeros ataques
• Ya tiene protección gestionada (Cloudflare, WAF, un formulario con antispam integrado) - aproveche primero sus límites y filtros, no duplique infraestructura desde cero

Si el tráfico y las integraciones crecen, vuelva al esquema completo de arriba.

Conclusión

El rate limit corta la frecuencia, la cola protege el backend y los presupuestos de integración, el antispam separa basura de leads. Solo funcionan juntos: límite sin cola tumba handlers síncronos; cola sin filtros reparte spam por el CRM; filtros sin límite se encarecen bajo DDoS.

Si necesita diseñar la protección de formularios y bots para su stack (límites, cola, cuarentena, monitorización) - contacte conmigo. Orientaciones de soporte y mejoras - en la página de precios.

Si necesita ayuda con el desarrollo, la implementación de IA o el soporte del sitio para su proyecto - escríbame.

Preguntas frecuentes

¿En qué se diferencia el rate limit del antispam?

El rate limit cuenta intentos; el antispam valora contenido y comportamiento. El límite frena el flood aunque las peticiones sean «limpias»; el antispam atrapa spam raro pero tóxico que aún cabe en el cupo.

¿Hace falta una cola si hay pocos leads?

Sí, si hay APIs externas, email o LLM. Incluso con poco tráfico, un timeout síncrono del CRM rompe la UX del formulario. La cola es barata en reposo y salva en el pico.

¿CAPTCHA es obligatorio en cada formulario?

No. Mejor challenge por riesgo: tras rachas de error, mala reputación de IP o score anómalo. Molesta menos a las personas y sigue cortando bots.

En un bot, ¿limitar por chat_id o por IP?

Ambos. chat_id frena el flood de un usuario; IP/token del webhook protege de updates falsos y escaneo. En grupos los límites suelen ser más duros que en privado.

¿Qué hacer con leads que parecen spam?

A cuarentena con revisión manual o entrega diferida, no a la papelera sin rastro. Si no, pierde un lead legítimo raro y no ve cómo evolucionan los patrones de ataque.

Términos del artículo

CRM — Customer Relationship Management — gestión de relaciones con clientes

SMS — Short Message Service — servicio de mensajes cortos

LLM — Large Language Model — modelo de lenguaje grande

endpoint — specific API URL that accepts requests — URL concreta de API que acepta peticiones

webhooks — HTTP callbacks when events happen — llamadas HTTP cuando ocurren eventos

rate limiting — enforcing a cap on requests per time window — aplicar un límite de peticiones por intervalo

timeout — max wait before aborting

worker — background job processor

backoff — growing wait between retries after failures — pausa creciente entre reintentos tras fallos

retry — automatic repeat of a failed request or job — repetición automática de una petición o tarea fallida

long polling — client waits on an open request until the server has news — el cliente mantiene la petición abierta hasta que el servidor avisa

CSRF — Cross-Site Request Forgery — falsificación de petición entre sitios

circuit breaker — switch that stops calling a failing dependency for a while — fusible: deja de llamar un rato a una dependencia que falla

dead letter — queue for messages that failed processing repeatedly — cola para mensajes que fallaron varias veces

CDN — Content Delivery Network — red de entrega de contenido

backend — server-side logic, APIs and data layer — lógica de servidor, APIs y capa de datos

MVP — Minimum Viable Product — producto mínimo viable

DDoS — Distributed Denial of Service — denegación de servicio distribuida