Lo que aprendí al diseñar integraciones de backend omnicanal
Esquema de intención compartida, estado de conversación eventualmente consistente y por qué el canal debería ser lo último que tu backend conozca.
Parte de Backend Craft
Omnicanal es una palabra que se utiliza mucho por personas que venden tableros de control. Lo que realmente significa es: un cliente comienza en WhatsApp, continúa en voz, termina en la web, y espera que tu sistema se mantenga al día.
El backend no debe saber qué canal es
La mayor victoria de cualquier proyecto omnicanal que he construido es esta regla:
El código de cumplimiento no debe ramificarse según el canal. Si lo hace, estás construyendo N productos.
La lógica de tu bot, tus prompts de LLM, tus actualizaciones de CRM —nada de eso debería importar si la entrada provino de SMS, voz, web o paloma mensajera. El adaptador de canal normaliza a un sobre común y lo entrega. Todo lo que viene después opera en intenciones y entidades, no en "la voz dice esto, WhatsApp dice aquello".
El estado de la conversación es eventualmente consistente
Los llamadores no esperan por tu retraso de replicación. Si el llamador escala de bot a agente a través de un cambio de canal, el agente necesita un estado que podría estar 500 ms detrás del borde.
Dos opciones que funcionan:
- Registro de conversación de escritor único identificado por cliente + sesión. Cada canal escribe eventos solo de adición. Los lectores proyectan.
- Instantánea "última conocida" idempotente que cualquier canal puede sobrescribir, con un sello de versión. Más simple, menos seguro.
Yo prefiero el registro. Solo de adición es aburrido y correcto.
El esquema de intenciones es el contrato
Si tu equipo de voz y tu equipo de chat definen intenciones de manera diferente, las fusionarás más tarde bajo presión de tiempo. Define una ontología de intenciones compartida desde el primer día. Versiona eso. Trata los cambios como cambios de API.
Lo que le diría a mi yo del pasado
- Construye el adaptador de canal al final. Primero haz que el cumplimiento sea correcto.
- Mide el éxito del cambio de canal como un KPI de primera clase. Es el único que prueba que el omnicanal funciona.
- Presupuesta para la observabilidad que abarque canales. Un rastro que muere cuando la voz pasa a la web no es un rastro.
Escrito por
Adrian Romo
Ingeniero Backend Senior que diseña APIs escalables en Python, arquitecturas sobre AWS Lambda, sistemas de voz e integraciones empresariales.
Relacionado
Sigue leyendo
Primitivas Ensambladas vs. una Plataforma
Construí un agente de voz usando primitivas en la nube, y funcionó. Desde entonces, fue reemplazado por una plataforma de voz diseñada específicamente para ese fin, y creo que fue la decisión correcta.
Seis publicaciones al día y el programador que aprendió a decir cuándo
Un pipeline social que publicaba un Reel al día y nada más, porque las cuotas por formato eran techos y nadie solicitaba los otros formatos.
Un planificador que no incorporará nada
La herramienta que decide cómo incorporar un nuevo servicio a mi homelab no tiene la capacidad de incorporarlo. Esa separación es el diseño, no una limitación.
Continúa
¿A dónde sigues?
Explora más textos técnicos, revisa los casos de estudio o escríbeme directo.