Diseñar una arquitectura backend que corra completamente en servidores exige responder preguntas fundamentales: ¿cómo escalar cuando la demanda crece?, ¿cómo garantizar que la aplicación nunca deje de funcionar? y ¿qué métricas usar para crecer o reducir recursos de forma automática. A continuación se desglosan los elementos clave de esta arquitectura tomando como caso práctico la aplicación Platzy Wallet.
¿Cómo se estructura la arquitectura desde el usuario hasta el servidor?
Todo parte del usuario [0:22]. La arquitectura debe pensarse siempre desde quien va a consumir la aplicación. A partir de ahí se construyen las capas en orden:
- DNS: el punto de entrada, en este caso
platzywallet.com, que resuelve la dirección del servicio [1:00].
- CDN más WAF: una capa combinada que acelera la entrega de contenido estático y protege contra ataques a nivel de red [1:12].
- API Gateway con autenticación y autorización: capa intermedia que valida quién puede acceder a los recursos del backend [1:30].
- Balanceador de aplicaciones: opera en la capa 7 del modelo OSI, es decir, trabaja con tráfico HTTPS. Su función es distribuir las peticiones entre los servidores disponibles usando un algoritmo como round-robin, que alterna las solicitudes entre el servidor de la zona de disponibilidad 1 y el de la zona 2 de forma secuencial [1:22].
¿Por qué distribuir servidores en zonas de disponibilidad?
Las zonas de disponibilidad (Availability Zones o AZ) son ubicaciones físicamente separadas dentro de una región de nube [2:08]. Colocar servidores en al menos dos zonas distintas garantiza alta disponibilidad, algo que se describe como no negociable en cualquier arquitectura profesional [2:30]. Si una zona falla, la otra sigue atendiendo usuarios sin interrupción.
¿Qué es el autoescalamiento y cómo funciona en servidores?
Cuando la base de usuarios pasa de unos pocos a cien mil, dos servidores no son suficientes. Aquí entra el grupo de autoescalamiento (autoscaling group) [3:30], un componente disponible en todos los proveedores de nube que permite que la cantidad de servidores crezca o se reduzca automáticamente.
Este tipo de crecimiento es escalamiento horizontal [4:20]: se replican nodos idénticos sin necesidad de apagar la aplicación, es decir, sin downtime.
¿Qué parámetros definen el autoescalamiento?
Para configurar el grupo de autoescalamiento se establecen tres valores [4:40]:
- Capacidad mínima: la cantidad más baja de servidores que la aplicación necesita para funcionar, por ejemplo, dos.
- Capacidad deseada: normalmente coincide con la mínima, distribuyendo un servidor por cada zona de disponibilidad.
- Capacidad máxima: el tope para evitar costos descontrolados, por ejemplo, ocho servidores. Esto es crucial ante un ataque de denegación de servicio que genere tráfico artificial masivo [5:10].
¿Sobre qué métricas se debe escalar?
Las reglas de autoescalamiento se definen mediante métricas de monitoreo [5:40]. Un ejemplo con CPU sería:
- CPU mayor al 60 %: incrementar un servidor [6:05].
- CPU mayor al 80 %: sumar dos servidores [6:20].
- CPU inferior al 60 %: restar un servidor [6:35].
- CPU inferior al 40 %: reducir en dos servidores, sin bajar nunca de la capacidad mínima [6:50].
Sin embargo, el consejo práctico es escalar sobre métricas de demanda en lugar de recursos técnicos como CPU o RAM [7:15]. Por ejemplo, si la cantidad de requests o usuarios concurrentes supera mil, se agrega un servidor; si supera cien mil, se agregan cuatro.
¿Qué ocurre cuando nace un nuevo servidor?
Cada servidor nuevo se crea a partir de una AMI (Amazon Machine Image), una imagen base que ya tiene todo el software preinstalado [7:55]. Esto permite replicar el entorno de forma consistente. No obstante, hay que considerar un tiempo de escalamiento de tres a cinco minutos [8:10] mientras se completan dos procesos:
- La creación del servidor a partir de la imagen.
- La verificación de salud por parte del balanceador antes de enviarle tráfico.
Además de la capa de servidores, la arquitectura completa incluye base de datos, almacenamiento, conexión híbrida, monitoreo, trazas, compliance y seguridad [8:30].
Si estás evaluando en qué tipo de infraestructura desplegar tu aplicación, entender estos tres ejes —autoescalamiento, distribución en zonas de disponibilidad y tiempo de respuesta ante picos— te dará criterios sólidos para tomar la mejor decisión. ¿Ya has trabajado con grupos de autoescalamiento en algún proveedor de nube? Comparte tu experiencia en los comentarios.
