ARQUITECTURA DE SISTEMAS

El Desafío de una Startup Moderna

¡Bienvenido a 498AS! Antes de sumergirnos en tecnologías específicas, entendamos por qué existe nuestra arquitectura y qué problemas resuelve.

Quiénes Somos

498AS es una startup en rápido crecimiento que construye múltiples productos:

• Dashboards para Clientes - Herramientas de visualización de datos e informes
• Agentes IA - Sistemas inteligentes que procesan datos y generan outputs
• Aplicaciones Web - Sitios corporativos, landing pages y productos SaaS

Nuestros clientes incluyen entidades corporativas como DIBA (Diputació de Barcelona), bancos y otras instituciones que requieren fiabilidad de nivel empresarial.

Los Desafíos Únicos que Enfrentamos

Nuestra Solución: Una Arquitectura por Capas

Para abordar estos desafíos, hemos diseñado una arquitectura con clara separación de responsabilidades:

Esta separación significa que un problema en un plano no se propaga a los demás. Un trabajo de IA desbocado no tirará un dashboard de cliente.

Conceptos Básicos de Infraestructura

Antes de explorar nuestras herramientas específicas, establezcamos un vocabulario común. Si ya estás familiarizado con estos conceptos, puedes ojear este capítulo rápidamente.

DNS - La Guía Telefónica de Internet

Tipos de registros DNS clave que usamos:

Proxy Inverso - El Director de Tráfico

Beneficios de los proxies inversos:

• Terminación SSL - Maneja el cifrado HTTPS en un solo lugar
• Balanceo de Carga - Distribuye el tráfico entre múltiples servidores
• Enrutamiento - Envía api.example.com al servidor API, app.example.com al servidor de app
• Seguridad - Oculta la estructura interna del servidor al mundo exterior

Usamos Caddy (via Coolify) como nuestro proxy inverso. Gestiona automáticamente los certificados SSL mediante Let's Encrypt.

Contenedores - Aplicaciones Portátiles

Beneficios clave:

• Consistencia - Funciona igual en todas partes (dev, staging, producción)
• Aislamiento - Cada contenedor está separado de los demás
• Eficiencia - Más ligero que las máquinas virtuales

Usamos contenedores Docker gestionados por Coolify.

OrbStack - Alternativa Ligera para Desarrollo Local

Beneficios clave de OrbStack:

• Arranque rápido - Inicia en segundos vs minutos con Docker Desktop
• Menor consumo de recursos - Usa significativamente menos RAM y CPU
• Compatibilidad total - Funciona con Docker CLI, Docker Compose y Kubernetes
• Integración nativa con macOS - Mejor experiencia de desarrollo

CI/CD - Despliegues Automatizados

Nuestro flujo CI/CD:

Colas de Mensajes - Procesamiento en Segundo Plano

Usamos Redis + BullMQ para colas. Casos de uso comunes:

• Procesar archivos Excel subidos
• Generar informes
• Llamar a APIs de IA (que pueden ser lentas)
• Enviar emails

Bases de Datos Vectoriales - Búsqueda Semántica

Ejemplo: Si buscas "problemas con el coche", una base de datos vectorial puede encontrar documentos sobre "averías de vehículos" o "fallos de automóvil" aunque esas palabras exactas no estén en tu consulta.

Usamos Convex para almacenamiento vectorial y búsqueda semántica en nuestros flujos de trabajo de IA.

El Modelo Mental de Arquitectura Cloud

Ahora construyamos un modelo mental de cómo encajan todas estas piezas.

El Viaje de una Petición

Cuando un usuario visita una de nuestras aplicaciones, esto es lo que sucede:

El Viaje de un Despliegue

Cuando un desarrollador sube código:

El Viaje de un Trabajo de IA

Cuando un usuario sube un archivo para procesamiento de IA:

Cloudflare - Capa de Edge y Seguridad

Qué Hace Cloudflare Por Nosotros

1. Gestión de DNS (DNS Autoritativo)

Cloudflare es nuestro proveedor de DNS. Cuando alguien visita nuestros dominios, Cloudflare le dice a su navegador dónde encontrarnos.

Nuestra configuración DNS:

• Dominios registrados en Dinahosting
• Nameservers apuntando a Cloudflare
• Registros DNS gestionados en el Dashboard de Cloudflare

2. Proxy Inverso (La Nube Naranja)

Cuando activas el icono de la nube naranja en un registro DNS, el tráfico fluye a través de Cloudflare en lugar de ir directamente a tu servidor.

3. Funcionalidades de Seguridad

4. Funcionalidades de Rendimiento

• Caché CDN - Assets estáticos servidos desde la ubicación Cloudflare más cercana
• TLS/SSL - Cifrado HTTPS manejado en el edge
• Compresión - Compresión automática Brotli/Gzip
• HTTP/2 y HTTP/3 - Protocolos modernos para carga más rápida

5. Servicios Adicionales de Cloudflare

• Workers/Pages - Funciones serverless en el edge para lógica personalizada
• R2 Object Storage - Almacenamiento compatible con S3 sin costes de egress
• Durable Objects - Coordinación serverless con estado
• API Shield - Validación de esquema y modelo de seguridad positivo para APIs

6. Zero Trust Access

Cloudflare Access nos permite proteger herramientas internas (como nuestro panel Coolify) sin VPN:

• Requiere autenticación para acceder a paneles de administración
• Restringe por dominio de email, IP o postura del dispositivo
• No hay necesidad de exponer interfaces de gestión públicamente

Limitaciones de Cloudflare a Considerar

• Límite de 100MB de subida en planes free/Pro (usar subida directa para archivos grandes)
• Límites de CPU de Workers - 10-50ms de tiempo CPU por petición
• Conexiones Websocket requieren configuración apropiada de timeout

Coolify - Despliegue y Orquestación

¿Por Qué Coolify?

Coolify nos da la experiencia de desarrollador de Heroku con control total sobre nuestra infraestructura:

Cómo Funciona Coolify

Arquitectura

Componentes Clave

• Panel de Control - Interfaz web para gestionar todo
• Docker Engine - Ejecuta todas las aplicaciones como contenedores
• Caddy/Traefik - Proxy inverso para enrutamiento y SSL
• Let's Encrypt - Gestión automática de certificados SSL

Limitaciones Actuales de Coolify

A partir de 2024, Coolify está en desarrollo activo pero tiene algunas limitaciones a tener en cuenta:

• Sin soporte Kubernetes (aún) - Solo Docker Swarm/standalone
• Sin balanceo de carga automático - Configuración manual o LB externo
• Sin HA incorporado - Instancia única de Coolify (¡haz backup de tu config!)
• Despliegue blue-green limitado - Solo rolling updates básicos

Estos son trade-offs aceptables para nuestra escala. Si superamos Coolify, podemos migrar a Kubernetes.

Flujo de Despliegue

GitHub - Control de Código y CI/CD

Estructura de la Organización

github.com/498AS/
├── startdesk-dashboard     # Aplicación dashboard de cliente
├── gorila                  # Sistema KONG para informes DIBA
├── 3cat-dashboard          # Dashboard proyecto 3Cat
├── prompt-kitchen          # Gestión de prompts IA
├── paw-influencers         # Analítica de influencers
└── [otros proyectos...]

Estrategia de Ramas

Capa de Datos - PostgreSQL, Redis y Convex

Nuestra capa de datos consiste en tres sistemas complementarios, cada uno optimizado para diferentes casos de uso.

PostgreSQL - La Fuente de Verdad

Cuándo Usar PostgreSQL

• Cuentas de usuario y datos de autenticación
• Entidades de negocio (proyectos, clientes, informes)
• Logs de auditoría y registros históricos
• Cualquier dato que requiera transacciones ACID
• Consultas complejas con JOINs

Redis - Rápido y Efímero

Cuándo Usar Redis

Convex - Tiempo Real y Vectores

Cuándo Usar Convex

• Búsqueda Vectorial (RAG) - Búsqueda de similitud semántica para contexto LLM
• Checkpoints de Proceso - Guardar estado de trabajos IA de larga duración
• Actualizaciones en Tiempo Real - Actualizaciones de dashboard en vivo
• Coordinación LLM - Seguimiento de miles de llamadas API a través de un flujo de trabajo

Ejemplo de Búsqueda Vectorial

// Schema con índice vectorial
import { defineSchema, defineTable } from "convex/server";
import { v } from "convex/values";

export default defineSchema({
  documents: defineTable({
    content: v.string(),
    embedding: v.array(v.float64()),  // Embedding vectorial
    metadata: v.object({...})
  }).vectorIndex("by_embedding", {
    vectorField: "embedding",
    dimensions: 1536,  // OpenAI text-embedding-ada-002 / text-embedding-3-small
    // Nota: text-embedding-3-large usa 3072 dimensiones
  })
});

Daytona - Sandboxes de Ejecución IA

Por Qué Daytona es Importante

Cómo Funciona Daytona

Daytona vs Ejecutar Localmente

Niveles de Precios de Daytona

Proveedores de Infraestructura - Hetzner, OVH y Dinahosting

Nuestra infraestructura corre sobre proveedores europeos, elegidos por su relación coste-efectividad, cumplimiento GDPR y buen rendimiento.

Hetzner Cloud

Servidor Hetzner Actual

OVH

Dinahosting

Visión General de la Configuración Actual

Veamos exactamente qué tenemos ejecutándose hoy. Este es el estado "AS-IS" desde el que estamos evolucionando.

Diagrama de Infraestructura Actual

Aplicaciones Actualmente en Ejecución

Lo Que Funciona Bien

Antes de discutir mejoras, reconozcamos lo que nuestra configuración actual hace bien.

Fortalezas de la Arquitectura Actual

Riesgos y Limitaciones Actuales

Ahora evaluemos honestamente los riesgos en nuestra configuración actual.

Riesgo 1: Densidad Por Host

Riesgo 2: Plano de Control Mezclado con Producción

Riesgo 3: Base de Datos No Aislada

Tabla Resumen de Riesgos

Principios de Arquitectura

Antes de profundizar en los detalles, establezcamos los principios que guían nuestra arquitectura objetivo.

Principio 1: Separar Planos

Principio 2: Reducir el Radio de Explosión

Principio 3: Mantener Agilidad

Principio 4: Seguridad por Diseño

Principio 5: Escalabilidad Coste-Efectiva

El Estado Objetivo

Diagrama de Arquitectura Objetivo

Roles de Servidores

Qué Cambia

Separación del Plano de Control

Aislamiento de Base de Datos

Hoja de Ruta de Migración

Migraremos incrementalmente, no todo de una vez. Cada fase entrega valor y reduce riesgo.

Principios de Migración

• Un cambio a la vez - No migrar todo simultáneamente
• Validar cada fase - Confirmar estabilidad antes de proceder
• Plan de rollback - Saber cómo deshacer cada cambio
• Continuidad de negocio - Sin tiempo de inactividad extendido para clientes

Operaciones Diarias y Flujos de Trabajo

Desplegando Código

Despliegue Estándar (Automático)

# 1. Haz tus cambios localmente
git add .
git commit -m "feat: add new dashboard widget"

# 2. Push a main (dispara auto-deploy)
git push origin main

# 3. Monitoriza el despliegue en el panel Coolify
# El despliegue típicamente completa en 1-2 minutos

Comprobando Estado de Aplicaciones

Desde Línea de Comandos

# SSH al servidor
ssh user@5.135.151.118

# Listar contenedores en ejecución
docker ps

# Ver logs de contenedor específico
docker logs <container_name> --tail 100

# Seguir logs en tiempo real
docker logs <container_name> -f

Trabajando con Bases de Datos

Conectando a PostgreSQL

# Desde el servidor
docker exec -it <postgres_container> psql -U postgres

# Listar bases de datos
\l

# Conectar a base de datos específica
\c database_name

# Listar tablas
\dt

# Salir
\q

Añadiendo una Nueva Aplicación

Prácticas de Seguridad

Control de Acceso

Checklist de Seguridad

Resolución de Problemas y Referencia Rápida

Problemas Comunes

Falla el Despliegue

Problemas de Aplicación

Referencia Rápida

URLs Importantes

Comandos Útiles

# Ver qué está corriendo
docker ps

# Ver logs de contenedor
docker logs <container> --tail 100

# Reiniciar un contenedor
docker restart <container>

# Verificar espacio en disco
df -h

# Verificar uso de memoria
free -h

# Probar resolución DNS
dig +short app.georadar.app

# Probar HTTPS
curl -I https://app.georadar.app

Enlaces de Documentación

• Coolify: coolify.io/docs
• Cloudflare: developers.cloudflare.com
• Daytona: daytona.io/docs
• Convex: docs.convex.dev
• Hetzner Cloud: docs.hetzner.com/cloud
• BullMQ: docs.bullmq.io
• Drizzle ORM: orm.drizzle.team

Los Cinco Planos de la Arquitectura 498AS

La arquitectura de 498AS se organiza en cinco planos con una clara separacion de responsabilidades, disenada para que los fallos en una capa no afecten a las demas.

1. Plano Edge (Seguridad y Trafico)

2. Plano de Control (Despliegue y Orquestacion)

3. Plano de Aplicacion (Logica y Producto)

4. Plano de Datos (Almacenamiento y Persistencia)

5. Plano de Ejecucion (Aislamiento de Cargas)

Comparativa con AWS

Una pregunta frecuente es si AWS puede sustituir nuestro stack actual. La respuesta corta es: en gran parte si, pero con matices importantes.

Componentes Reemplazables con AWS

Donde NO Hay Sustitucion Simple

Trade-offs al "AWS-izar" el Stack

Tabla de Equivalencias Completa