Construyendo plataformas SaaS escalables: patrones de arquitectura para más de 10M de usuarios

El desafío de la escalabilidad

Construir una plataforma SaaS que funcione para 100 usuarios es trivial. Construir una que funcione para 10 millones — manteniendo tiempos de respuesta por debajo de 100 ms, un 99,99% de disponibilidad, y un equipo lo suficientemente pequeño como para moverse rápido — es uno de los problemas más difíciles en la ingeniería de software.

Esta guía documenta las decisiones arquitectónicas y los patrones que los mejores equipos de ingeniería usan para lograrlo.

La pirámide de la escalabilidad

Piensa en la escalabilidad como una pirámide, construida de abajo hacia arriba:

1. Capa de datos (diseño de base de datos, sharding, replicación)
2. Capa de aplicación (servicios sin estado, caché)
3. Capa de infraestructura (balanceo de carga, auto-escalado)
4. Capa de red (CDN, edge computing)

Si te equivocas en las capas inferiores, ninguna cantidad de infraestructura te salvará.

Arquitectura de bases de datos

Patrones de multi-tenencia

Hay tres enfoques comunes para el diseño de bases de datos multi-tenant:

Para la mayoría de las plataformas SaaS, recomendamos comenzar con base de datos compartida, esquemas separados y migrar a los principales clientes empresariales a bases de datos dedicadas a medida que crecen.

Réplicas de lectura y CQRS

// Patrón CQRS: separar los modelos de lectura y escritura
class OrderCommandService {
  async createOrder(data: CreateOrderDTO) {
    const order = await this.db.write.orders.create(data);
    await this.eventBus.publish('order.created', order);
    return order;
  }
}

class OrderQueryService {
  async getOrderHistory(userId: string) {
    // Leer desde la réplica — ¡sin bloqueos de escritura!
    return this.db.readReplica.orders.findMany({
      where: { userId },
      include: { items: true, payments: true },
    });
  }
}

Arquitectura orientada a eventos

El arma secreta de las plataformas SaaS escalables es la arquitectura orientada a eventos. En lugar de que los servicios se llamen directamente entre sí, se comunican a través de eventos.

Beneficios

• Desacoplamiento: los servicios no necesitan conocerse entre sí
• Resiliencia: si un servicio está caído, los eventos se ponen en cola y se procesan cuando se recupera
• Escalabilidad: cada servicio puede escalar de forma independiente según su carga

Implementación con Kafka

// Productor — cuando se crea un pedido
await kafka.send({
  topic: 'order-events',
  messages: [{
    key: order.id,
    value: JSON.stringify({
      type: 'ORDER_CREATED',
      payload: order,
      timestamp: new Date().toISOString(),
    }),
  }],
});

// Consumidor — servicio de facturación
kafka.run({
  eachMessage: async ({ message }) => {
    const event = JSON.parse(message.value!.toString());
    if (event.type === 'ORDER_CREATED') {
      await billingService.processPayment(event.payload);
    }
  },
});

Estrategia de caché

Los tres niveles de caché en un SaaS moderno:

1. Caché del navegador: activos estáticos, respuestas de API con encabezados de caché
2. Caché de CDN: contenido distribuido geográficamente
3. Caché de aplicación: Redis para datos de sesión, resultados calculados y consultas frecuentes a la base de datos

Regla general: si una consulta se ejecuta más de una vez por segundo y su resultado cambia menos de una vez por minuto, debería almacenarse en caché.

Despliegues sin tiempo de inactividad

El tiempo de inactividad es inaceptable para las plataformas SaaS. Lograr despliegues sin tiempo de inactividad requiere:

1. Despliegues blue-green: ejecutar dos entornos de producción idénticos
2. Feature flags: desplegar código sin habilitar funciones
3. Estrategias de migración de bases de datos: patrón de expansión/contracción para cambios de esquema
4. Health checks: cambio automático de tráfico según el estado del servicio

Las plataformas que ganan son las que pueden lanzar sin miedo — desplegando 10 veces al día sin romper la confianza de sus usuarios.