Arquitectura de sistemas de alta carga — Blog de Robosoft
Alta carga no significa solo más tráfico: significa que cada supuesto que funcionaba a pequeña escala hay que volver a comprobarlo.
Diseñar para el escalado horizontal desde el principio
Los sistemas que escalan añadiendo más máquinas, en lugar de máquinas más grandes, evitan los techos rígidos. Adaptar esto cuando un monolito ya soporta la carga es mucho más caro que planificarlo desde el inicio.
Desacoplar lo que no necesita ser síncrono
Las colas de mensajes permiten que las partes lentas o poco fiables de un sistema fallen sin tumbar todo lo que está conectado a ellas. No todas las operaciones necesitan una respuesta inmediata, y decidir cuáles la necesitan es una decisión de arquitectura clave.
Planificar para el fallo, no solo para el éxito
A gran escala, siempre hay algo fallando en algún sitio: un servidor, un enlace de red, una dependencia. Los circuit breakers, los reintentos con espera progresiva y la degradación controlada son lo que evita que un fallo parcial se convierta en una caída total.
Errores habituales
El error más habitual es optimizar para una escala que aún no tienes a costa de la velocidad de entrega. El segundo más habitual es el contrario: ignorar por completo el escalado hasta que un incidente obliga a una reconstrucción de emergencia. El enfoque correcto es diseñar las costuras (dónde podría dividirse después un monolito, dónde podría añadirse después una cola) sin construirlas necesariamente todas el primer día.
Una lista de comprobación práctica
- ¿Se puede reiniciar cualquier componente sin tumbar todo el sistema?
- ¿Una dependencia lenta degrada el servicio de forma controlada o provoca un efecto en cascada?
- ¿Hay un resultado de prueba de carga de los últimos seis meses, y no solo una suposición?
- ¿Puedes añadir capacidad sin un despliegue, solo con un cambio de configuración?
¿Diseñas para una carga que aún no ves?
Mejor planificarlo ahora que reconstruir bajo presión más adelante.
