Plataforma SaaS · Backend Specialist
Optimización de rendimiento y escalabilidad horizontal
El Problema
La plataforma SaaS sufría de tiempos de respuesta elevados (>2s) en horarios punta, con picos de carga que saturaban la base de datos principal.
Decisiones de Arquitectura (ADRs)
- Contexto: La base de datos SQL Server era el único cuello de botella; todas las consultas repetitivas de lectura golpeaban directamente a los discos.
- Decisión: Partición de la base de datos (sharding) por tenant y uso de Redis como caché de primer nivel.
- Alternativas consideradas: Migrar a NoSQL (descartado por necesidad de consistencia ACID en facturación).
- Resultado: Descarga del 85% de las lecturas hacia Redis y operaciones de escritura asíncronas vía RabbitMQ.
- Consecuencias: Mayor complejidad en la invalidación de caché y necesidad de monitoreo distribuido, mitigado con despliegues Blue-Green en Kubernetes.
graph LR A[Client] –> B[Load Balancer] B –> C[API Gateway] C –> D[Service A] C –> E[Service B] D –> F[Redis Cache] E –> G[SQL Server Primary] G –> H[SQL Server Replicas]
Trade-offs
Se aumentó la complejidad operativa (monitoreo de cachés, consistencia eventual) pero se logró escalar a 10x el tráfico sin degradar la experiencia.
Resultados
- Latencia reducida de 2.3s a 300ms (p95).
- Capacidad para manejar 50k peticiones concurrentes.
- Cero downtime en los últimos 12 meses (blue-green deployments).