Cómo Implementar Memoria Persistente en Chatbots de Telegram con PostgreSQL

Cómo Implementar Memoria Persistente en Chatbots de Telegram con PostgreSQL

Introducción

Los chatbots conversacionales modernos enfrentan un desafío crítico: mantener el contexto entre sesiones. Imagina un asistente que olvida toda tu conversación cada vez que reinicias el servidor. Frustrante, ¿verdad? En esta sesión técnica de 4 horas, migramos un bot de Telegram desde memoria temporal (Window Buffer) a memoria persistente con PostgreSQL, mejorando radicalmente la experiencia del usuario.

Este artículo documenta el proceso completo, desde la arquitectura de base de datos hasta la integración con n8n, incluyendo las decisiones técnicas que enfrentamos y cómo las resolvimos.

El Problema: Memoria Volátil en Bots Conversacionales

Los sistemas de chatbot tradicionales almacenan el historial de conversación en memoria RAM. Esto funciona mientras el servidor está activo, pero presenta tres problemas graves:

1. Pérdida de contexto: Cada reinicio borra todo el historial
2. Sin auditoría: Imposible revisar conversaciones pasadas
3. Escalabilidad limitada: La RAM se llena con múltiples usuarios activos

Nuestro cliente, una clínica dental con bot en Telegram, necesitaba que cada usuario mantuviera su historial independiente, incluso después de actualizaciones del sistema.

La Solución: PostgreSQL Chat Memory

Arquitectura de la Base de Datos

Diseñamos una tabla simple pero efectiva en el servidor `vps2`, dentro del container `n8n-postgres`:

CREATE TABLE mcdental_chat_memory (
id SERIAL PRIMARY KEY,
session_id VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL,
content TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
metadata JSONB
);

Decisiones de diseño clave:

• `session_id`: Vinculado al `chat_id` de Telegram (cada usuario tiene su historial separado)
• `role`: Identifica si el mensaje viene del usuario o del bot
• `metadata JSONB`: Flexibilidad para agregar datos adicionales sin alterar el schema
• `created_at`: Permite ordenar cronológicamente y hacer análisis temporal

Integración con n8n

La plataforma de automatización n8n ofrece el nodo "Postgres Chat Memory", que abstrae la complejidad de gestionar el historial. Configuramos:

• Credencial n8n: Conexión directa al container `n8n-postgres`
• Session key: `{{ $json.message.chat.id }}` (dinámico por usuario)
• Workflow version: v39 (actualizado desde v38 con Window Buffer)

Esta configuración garantiza que Irving y Mario (los dos administradores del bot) tengan historiales completamente separados.

Decisiones Técnicas y Alternativas Evaluadas

¿Por qué PostgreSQL y no Window Buffer?

| Criterio | Window Buffer | PostgreSQL |

|----------|---------------|------------|

| Persistencia | ❌ Se pierde al reiniciar | ✅ Permanente |

| Auditoría | ❌ No disponible | ✅ Queries SQL |

| Escalabilidad | ⚠️ Limitada por RAM | ✅ Disco + índices |

| Complejidad | ✅ Plug & play | ⚠️ Requiere DB |

La balanza se inclinó hacia PostgreSQL porque el cliente necesitaba revisar conversaciones pasadas para mejorar el servicio.

¿Por qué `n8ndb` y no un servidor separado?

Evaluamos usar el container `postgres` en `mylinuxserver-remote`, pero descubrimos que era para otra aplicación. Usar `vps2` (el mismo servidor que ejecuta n8n) eliminó latencia de red y simplificó la administración de credenciales.

Problemas Encontrados y Soluciones

Problema 1: API de n8n Devolvía "Unauthorized"

Al intentar actualizar el workflow vía REST API, recibimos errores de autenticación. Solución: Usamos SSH + `docker exec` para acceder directamente al container:

ssh vps2 "docker exec -i n8n-postgres psql -U n8n -d n8ndb"

Esta técnica es más confiable que depender de APIs que pueden tener problemas de tokens.

Problema 2: Confusión de Containers PostgreSQL

Había múltiples containers `postgres` en diferentes servidores. Solución: Documentamos claramente:

• `mylinuxserver-remote/postgres`: Otra aplicación, NO tocar
• `vps2/n8n-postgres`: Base de datos oficial de n8n, usar este

Trabajo Complementario: Investigación DNS y Facebook

Paralelamente a la implementación de PostgreSQL, realizamos dos investigaciones:

DNS del Cliente

Descubrimos que el dominio del cliente apunta a `69.16.244.106` (reverse DNS: `mst.mirecargatelcel.com`). El panel de administración DNS tiene un logo distintivo "cuadrado amarillo con esquina mordida", pero la URL exacta permanece desconocida hasta recibir más información.

Guía de Verificación Facebook para n8n

Creamos un documento completo (`GUIA_VERIFICACION_FACEBOOK_N8N.md`) con 4 fases:

1. Centralizar páginas en Business Manager
2. Business Verification (KYC) de Meta
3. Crear Meta App + System User
4. Arquitectura workflow n8n con Facebook Messenger

Este recurso será clave para futuros clientes que necesiten integrar bots con Facebook.

Estado Actual y Próximos Pasos

El workflow está completamente configurado (v39) con PostgreSQL Memory. Solo falta una prueba manual enviando un mensaje a `@McDentalCalendarBot` para verificar que:

1. El historial se almacena en `mcdental_chat_memory`
2. Las sesiones se separan correctamente por `chat_id`
3. El bot recuerda conversaciones anteriores después de reiniciar n8n

Documentación completada:

• `ESTADO_SESION_2026-01-16.md`: Snapshot de la sesión
• `README_MARIO.md`: Actualizado con nuevos workflows
• `GUIA_VERIFICACION_FACEBOOK_N8N.md`: Proceso completo de verificación

Conclusión: Tres Lecciones Clave

1. La persistencia es no negociable en producción. Window Buffer es excelente para prototipos, pero sistemas reales necesitan bases de datos. 2. La simplicidad arquitectónica reduce errores. Colocar la tabla en el mismo servidor que n8n eliminó múltiples puntos de fallo. 3. Documentar decisiones técnicas ahorra tiempo futuro. Cada "¿por qué usamos X en lugar de Y?" respondido hoy es una hora ahorrada mañana.

Si estás construyendo chatbots conversacionales, considera PostgreSQL Memory desde el inicio. Tu yo del futuro (y tus usuarios) te lo agradecerán.