Español
Arquitectura
Vista General

Vista General de Arquitectura

Entendiendo cómo funciona ReliaPulse internamente.

Vista General del Sistema

┌─────────────────────────────────────────────────────────────────┐
│                         Load Balancer                            │
└─────────────────────────────────────────────────────────────────┘
                               │
               ┌───────────────┼───────────────┐
               ▼               ▼               ▼
       ┌───────────┐   ┌───────────┐   ┌───────────┐
       │  Next.js  │   │  Next.js  │   │  Next.js  │
       │  App (1)  │   │  App (2)  │   │  App (n)  │
       └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
             │               │               │
             └───────────────┼───────────────┘
                             │
             ┌───────────────┼───────────────┐
             ▼               ▼               ▼
       ┌───────────┐   ┌───────────┐   ┌───────────┐
       │ PostgreSQL│   │   Redis   │   │  Workers  │
       └───────────┘   └───────────┘   └───────────┘

Componentes Core

Aplicación Next.js

La aplicación principal maneja:

  • UI del Dashboard (React Server Components)
  • Endpoints API (Route Handlers)
  • Páginas de estado públicas (Server-rendered)
  • Autenticación (NextAuth.js)

Base de Datos PostgreSQL

Almacén de datos primario para:

  • Organizaciones y usuarios
  • Componentes y estado
  • Incidentes y actualizaciones
  • Configuración y ajustes

Redis

Usado para:

  • Colas de trabajos en segundo plano (BullMQ)
  • Almacenamiento de sesiones
  • Contadores de rate limiting
  • Caché (opcional)

Workers en Segundo Plano

Procesos separados que manejan:

  • Monitoreo de uptime (health checks)
  • Polling de métricas (integraciones externas)
  • Entrega de notificaciones
  • Limpieza de datos

Flujo de Datos

Creación de Incidente

Usuario crea incidente
        │
        ▼
   API Route Handler
        │
        ├─► PostgreSQL (guardar incidente)
        │
        └─► Cola Redis (trabajos de notificación)
                │
                ▼
           Proceso Worker
                │
                ├─► Email/SMS/Webhook
                │
                └─► Alertas On-call

Flujo de Health Check

Scheduler (Worker)
        │
        ▼
   Request HTTP al Target
        │
        ▼
   Evaluar Condiciones
        │
        ├─► Éxito: Actualizar estado del componente
        │
        └─► Fallo: Verificar umbral
                │
                ├─► Bajo umbral: Marcar como fallido
                │
                └─► Sobre umbral: Crear incidente
                        │
                        └─► Enviar notificaciones

Flujo de Polling de Métricas

Scheduler (Worker)
        │
        ▼
   Consultar API Externa (Datadog, Prometheus, etc.)
        │
        ▼
   Parsear Respuesta
        │
        ├─► Almacenar data points
        │
        ├─► Verificar umbrales
        │
        └─► Actualizar estado del componente

Multi-Tenancy

ReliaPulse usa un modelo de multi-tenancy de base de datos única:

Aislamiento de Organización

  • Cada modelo de datos incluye organizationId
  • Todas las consultas filtran por organización
  • Las rutas API validan acceso a la organización
  • No hay acceso a datos entre organizaciones

Contexto de Request

// Middleware extrae organización de la sesión
const session = await auth();
const organizationId = session.user.organizationId;
 
// Todas las consultas de DB incluyen filtro de organización
const components = await prisma.component.findMany({
  where: { organizationId }
});

Autenticación

Sistema de Autenticación Dual

Request
   │
   ├─► Verificar header Authorization
   │       │
   │       └─► ¿API Key encontrada? ─► Validar key ─► Sesión sintética
   │
   └─► Sin API key ─► Verificar cookie de sesión ─► Auth de sesión

Flujo de Sesión

  1. Usuario inicia sesión vía NextAuth.js
  2. Sesión almacenada en JWT (o base de datos)
  3. Cookie enviada con cada request
  4. Middleware valida sesión

Flujo de API Key

  1. Request incluye Authorization: Bearer sk_live_xxx
  2. Key es hasheada y buscada
  3. Permisos verificados contra los requeridos
  4. Sesión sintética creada para el request

Escalabilidad

Escalamiento Horizontal

  • Servidores de app: Sin estado, escalan detrás del load balancer
  • Workers: Escalan añadiendo más procesos
  • Base de datos: Usar réplicas de lectura para consultas
  • Redis: Modo cluster para alta disponibilidad

Optimizaciones de Rendimiento

  • Server components (menos JS en cliente)
  • Optimización de consultas de DB (índices, batching)
  • Caché de respuestas (donde es apropiado)
  • Connection pooling (Prisma)

Arquitectura de Despliegue

Docker Compose (Desarrollo/Pequeña Escala)

docker-compose.yml
├── app (Next.js)
├── worker (BullMQ workers)
├── db (PostgreSQL)
├── redis (Redis)
└── adminer (Admin de DB)

Kubernetes (Producción)

├── Deployments
│   ├── app (replicas: 3)
│   └── worker (replicas: 2)
├── Services
│   ├── app-service
│   └── worker-service (interno)
├── Ingress
│   └── ingress principal
└── Externos
    ├── RDS/Cloud SQL
    └── ElastiCache/Cloud Memorystore

Documentación Relacionada

Git SyncStack Tecnológico