Conversaciones vs transacciones
Dos modelos mentales para diseñar mensajería y cómo afectan tu arquitectura.
Una transacción es un mensaje que se dispara por un evento y termina ahí: un código, un recibo, una alerta. Una conversación es un intercambio con estado, donde cada mensaje depende de los anteriores.
Lo que cambia en la arquitectura
- Las transacciones se modelan como colas: evento → plantilla → envío → estado.
- Las conversaciones necesitan una sesión: quién es el usuario, en qué paso está, cuándo expira.
- Las transacciones toleran latencia de segundos; las conversaciones se sienten rotas si responden en más de 2–3 segundos.
Sesiones con expiración
Una sesión conversacional debe expirar. Si el usuario vuelve tres días después y escribe "sí", ¿a qué está respondiendo? Define un TTL por flujo y, al expirar, reinicia con un saludo que dé contexto.
Ventanas de conversación
Un mensaje transaccional es un evento aislado: el sistema avisa y el usuario lee. Una conversación es un intercambio con estado, que puede durar minutos o días. La diferencia afecta la facturación —varios canales cobran por conversación y no por mensaje— y también tu modelo de datos.
Modela la conversación como una entidad propia, con apertura, último mensaje entrante, agente asignado y cierre. Así podrás saber si una respuesta cae dentro de la ventana permitida, cuánto cuesta cada hilo y cuánto tarda tu equipo en resolverlo.
Cuando un mensaje transaccional genera una respuesta del usuario, esa respuesta abre una conversación. Tu sistema debe enrutarla al lugar correcto: un bot, una cola de agentes o, como mínimo, un acuse automático que diga qué hacer.