Por qué un bot de WhatsApp es un sistema, no un chat

La demo es engañosamente simple: llega un mensaje, llamas al modelo, respondes. Cinco líneas. En producción, esas cinco líneas se convierten en un sistema. Te contamos por qué.

El problema del “200 rápido”

WhatsApp manda los mensajes a tu webhook y espera una respuesta inmediata. Si tardas —y generar imágenes con IA tarda segundos— Meta asume que fallaste y reintenta el mismo mensaje.

¿La consecuencia? Si tu webhook genera las imágenes en el momento, cada reintento dispara otra generación. Acabas de pagar dos, tres, cuatro veces por la misma respuesta. En un servicio donde cada generación cuesta dinero, eso es una sangría.

La solución es separar dos cosas que parecen una:

1. Acusar recibo (responder 200 en milisegundos) y encolar el trabajo.
2. Hacer el trabajo (generar) en un proceso aparte que lee de la cola.

Nosotros usamos una cola (Cloud Tasks) que vuelve a llamar a nuestro propio servicio. El webhook nunca toca la IA: solo valida, encola y responde.

Pero las colas también reintentan

Has resuelto los reintentos de Meta… y has heredado los de la cola. Cloud Tasks es at-least-once: puede entregar la misma tarea más de una vez. Si no haces nada, vuelves al punto de partida: generaciones duplicadas.

La defensa es un claim de deduplicación atómico: antes de generar, intentas “reclamar” ese message_id en una transacción de base de datos. Si ya estaba reclamado, paras. Si no, lo marcas y sigues. Atómico, porque dos entregas simultáneas no pueden reclamar lo mismo.

La firma, la autenticación y el endpoint abierto

Tu webhook es público: cualquiera en internet puede enviarle un POST. Hay que validar la firma de cada petición (un HMAC con tu secreto de app) y rechazar lo que no cuadre. Y el endpoint interno que hace el trabajo de pago debe exigir autenticación (OIDC): si lo dejas abierto, cualquiera puede disparar generaciones a tu costa.

La máquina de estados que no se cuelga

Una conversación tiene fases: pedir nombre, tema, estilo, generar, elegir, comprar. Eso es una máquina de estados. Y tiene que sobrevivir a la realidad: ¿qué pasa si la IA falla a mitad? ¿Si el usuario manda un audio donde esperabas texto? ¿Si vuelve tres horas después? ¿Si pulsa “generar” dos veces seguidas?

Cada uno de esos casos es una rama que, si no la contemplas, se convierte en un bot colgado o en un cobro doble. El estado generando es un cerrojo; un fallo de la IA revierte a un estado seguro; un mensaje fuera de guion no avanza la conversación.

Y encima, los límites

Como cada generación cuesta, necesitas un rate limit que frene el abuso sin molestar al uso normal, comprobado de forma transaccional antes de cada ronda. Y métricas para afinarlo con datos reales, no a ojo.

La moraleja

Nada de esto se ve en la conversación. El cliente solo escribe “quiero un regalo” y recibe diseños. Pero debajo hay colas, transacciones, firmas, autenticación, una máquina de estados y límites — el andamiaje invisible que separa una demo de algo que puedes dejar funcionando sin vigilarlo.

Construir eso una vez, bien, es exactamente el trabajo que una tienda no debería tener que hacer. Por eso existe Taituri.

— El equipo de Taituri