Arquitectura de Microservicios Multi-Bot: 6 Asistentes Telegram en un Solo VPS

Arquitectura de Microservicios Multi-Bot: 6 Asistentes Telegram en un Solo VPS

Arquitectura de Microservicios Multi-Bot: 6 Asistentes Telegram en un Solo VPS

Introducción

En el ecosistema de automatización empresarial, gestionar múltiples asistentes conversacionales de forma eficiente es un desafío técnico real. Este artículo documenta una arquitectura de producción que orquesta 6 bots de Telegram independientes, cada uno con lógica de negocio específica, ejecutándose en un único servidor VPS mediante contenedores Docker.

La solución combina FastAPI para endpoints REST, Flask para procesamiento de comandos con Gemini AI, y n8n para flujos de trabajo visuales. Todo detrás de Traefik como reverse proxy con SSL automático.

Arquitectura del Sistema

Componentes Principales

La infraestructura se divide en dos capas principales:

Capa de APIs (bot-system)

  • bot-api (Puerto 3000): FastAPI con uvicorn. Maneja webhooks de Telegram, endpoints REST y envío de mensajes.
  • bot-proxy (Puerto 3010): Flask server que procesa llamadas a Gemini AI y ejecuta comandos específicos de cada bot.

Capa de Automatización (n8n-stack)

  • n8n (Puerto 5678): Orquestador de workflows con interfaz visual.
  • Traefik (Puertos 80/443): Reverse proxy con Let's Encrypt automático.
  • Redis & PostgreSQL: Almacenamiento para n8n.

Estructura de Directorios

vps2-bot-system/
├── docker-compose.yml
├── Dockerfile (Python 3.12)
├── code/
│   ├── claude_proxy.py (369KB - 6 bots)
│   ├── deploy-api/
│   │   └── main.py (293KB)
│   ├── emma_prestamos_api.py
│   ├── carlitos_prestamos_api.py
│   └── extract_insights.py
└── n8n-config/
├── docker-compose.yml
└── Dockerfile.n8n

Configuración de Bots

Cada uno de los 6 bots activos tiene su propio directorio de datos y configuración:

| ID Cliente | Tipo de Servicio | Directorio Datos |

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

| er0002 | Gestión de préstamos | `/opt/bot-system/data/er0002/` |

| cr0001 | Gestión de préstamos | `/opt/bot-system/data/cr0001/` |

| ac0001 | Control de chatarrera | `/opt/bot-system/data/ac0001/` |

| av0004 | Asistente general | `/opt/bot-system/data/av0004/` |

| gr0002 | Gestión de negocio | `/opt/bot-system/data/gr0002/` |

| bg0001 | Asistente ejecutivo | `/opt/bot-system/data/bg0001/` |

Esta separación permite:

  • Aislamiento de datos entre clientes
  • Configuración independiente por bot
  • Escalado granular por servicio
  • Auditoría por cliente

Flujo de Trabajo Operacional

Desarrollo Local y Sincronización

El flujo de desarrollo mantiene un respaldo local sincronizado con producción:

1. Subir cambios al VPS

scp code/claude_proxy.py vps2:/opt/bot-system/code/
scp code/deploy-api/main.py vps2:/opt/bot-system/code/deploy-api/

2. Reiniciar contenedores

ssh vps2 "cd /opt/bot-system && docker compose restart"

3. Monitorear logs en tiempo real

ssh vps2 "docker logs -f bot-api --tail 50"
ssh vps2 "docker logs -f bot-proxy --tail 50"

Este patrón permite:

  • Hot reload sin downtime completo
  • Rollback rápido manteniendo versión local
  • Debugging remoto con logs en tiempo real

Integración con Gemini AI

El `claude_proxy.py` (369KB) actúa como intermediario entre Telegram y Gemini. Características clave:

  • Procesamiento de comandos semánticos: Detecta intenciones del usuario usando NLP.
  • Routing por cliente: Cada bot usa su propia API key de Gemini.
  • Caché de respuestas frecuentes: FAQ bypass para consultas repetitivas.
  • Formato de bloques semánticos: Similar a `[REGISTRAR_COMPRA]{json}[/REGISTRAR_COMPRA]`.

Networking y Seguridad

Docker Networking

Regla crítica: Los contenedores NO pueden usar `localhost` entre sí. Se debe usar nombres de servicio: 
❌ Incorrecto

CLAUDE_PROXY = "http://localhost:3010"

✅ Correcto

CLAUDE_PROXY = "http://bot-proxy:3010"

Whitelist de IPs

El `claude_proxy.py` solo acepta peticiones de:

  • `127.0.0.1` (localhost)
  • `::1` (IPv6 localhost)
  • `172.x.x.x` (Red interna Docker)

SSL y Dominio

Traefik maneja automáticamente:

  • Certificado Let's Encrypt para `bot.varelainsights.com`
  • Renovación automática cada 90 días
  • Redirección HTTP → HTTPS

Lecciones Aprendidas

1. Path Fixing en Migración

Cuando se migró desde un servidor anterior, se requirieron 49 correcciones de rutas en `main.py`:

Antes

/home/emma/prestamos.json

Después

/data/er0002/prestamos.json

2. Docker Compose Networking

Se identificaron 17 referencias a `localhost` que debían cambiar a nombres de servicio:

claude_proxy.py

requests.post('http://bot-api:3000/send', ...)

3. Traefik Registration Delay

Después de reiniciar contenedores, esperar ~15 segundos para que Traefik re-registre las rutas.

Conclusión

Esta arquitectura demuestra que es posible gestionar múltiples bots conversacionales en producción sin complejidad excesiva. Los puntos clave son:

  1. Separación de responsabilidades: FastAPI para APIs, Flask para procesamiento IA, n8n para workflows.
  2. Aislamiento por cliente: Cada bot tiene su sandbox de datos independiente.
  3. Sincronización continua: Respaldo local que permite desarrollo rápido y rollback seguro.

La solución soporta 6 bots activos con un solo VPS de recursos modestos, procesando comandos con Gemini AI y manteniendo disponibilidad 24/7 mediante Docker Compose y Traefik.

Regresar al blog

Deja un comentario