Express.js
Escalado de aplicaciones Express
Explica cómo escalar Express.js horizontalmente, externalizar estado, dimensionar pools y coordinar sesiones, caché, colas y conexiones persistentes.
- Última actualización
- Actualizada
- Nivel
- Profundización
Express.js
Explica cómo escalar Express.js horizontalmente, externalizar estado, dimensionar pools y coordinar sesiones, caché, colas y conexiones persistentes.
Escalar Express significa ejecutar más capacidad sin depender del estado local de una instancia. El límite real suele estar en PostgreSQL, servicios externos, memoria o coordinación, no en el router.
load balancer
↓
instance A instance B instance C
↓ ↓ ↓
shared database / cache / broker / storageCada instancia debe poder procesar una request equivalente. El estado que necesita sobrevivir o compartirse no puede vivir únicamente en memoria local.
Más CPU/memoria para una instancia. Es simple, pero tiene límite y dominio de fallo mayor.
Más instancias. Mejora capacidad y disponibilidad, pero exige coordinación de estado, conexiones y eventos.
Normalmente se combinan.
“Stateless” significa que una request no depende de memoria de una instancia anterior. No significa que el sistema no tenga estado; el estado vive en DB, session store, cache u otros servicios.
Problemas de estado local:
Algoritmos incluyen round-robin, least connections y hashing. El balanceador también maneja health, TLS y connection reuse.
Una distribución uniforme de requests no garantiza carga uniforme: una exportación puede costar cientos de GET simples.
Fijan un cliente a una instancia. Pueden simplificar estado local temporal, pero:
Úsalas solo si el protocolo lo requiere y existe recuperación.
Cada instancia agrega conexiones:
replicas × pool max
≤ conexiones disponibles para appEscalar pods sin ajustar pool puede saturar DB. PgBouncer o pooling externo puede ayudar, pero cambia semántica de session/prepared statements según modo.
Señales posibles:
CPU baja con pool saturado no significa capacidad libre. Elige métricas relacionadas con el cuello real.
Más instancias no resuelve una dependencia caída. Aplica:
Rechazar rápido puede preservar funciones críticas.
Usa store compartido o tokens según threat model. Si el store cae, decide si login y requests existentes fallan; no mantengas comportamiento ambiguo por instancia.
Cache local tiene hits diferentes por instancia y se vacía en rollout. Puede ser L1 delante de Redis L2, con invalidación/versiones. No asumas coherencia inmediata.
Un contador por proceso multiplica el límite por réplicas. Para límites globales usa edge/gateway o store compartido. Mantén límites locales como defensa adicional ante saturación.
Workers escalan separadamente de HTTP. La cola distribuye jobs y controla concurrencia. No aumentes workers sin considerar proveedor, DB y orden por entidad.
Conexiones permanecen en una instancia. Un broker distribuye eventos. Mide conexiones, buffers y reconnect storms durante deploy.
Object storage permite acceso desde cualquier instancia. Filesystem local no es compartido y suele ser efímero.
No introduzcas un lock distribuido para cualquier coordinación. Prefiere:
Locks distribuidos necesitan TTL, fencing tokens y manejo de pausas/fallos.
Un cron dentro de cada instancia se ejecuta N veces. Usa scheduler externo, job único o lock coordinado. El job debe seguir siendo idempotente.
Todas las instancias deberían usar el mismo artifact y config versionada. Rollouts graduales implican convivencia de versiones; contratos y schema deben ser compatibles.
DomiSys escala de 2 a 10 pods:
Sin estos cambios, diez pods podrían empeorar el sistema.
Múltiples instancias protegen contra fallo de proceso/host, pero no contra:
Disponibilidad requiere redundancia y procedimientos en cada componente crítico.
Mide capacidad por instancia con límites reales. Mantén headroom para spikes y pérdida de una réplica.
capacidad requerida
÷ capacidad segura por instancia
+ margen y tolerancia a falloAutoscaling agresivo puede elevar coste y presionar DB. Escalar down demasiado rápido corta conexiones o produce cold starts. Configura stabilization windows.
Mantenimiento y migración a Express 5 trata upgrades de framework sin confundir cambios de versión con arquitectura.