System Design
Diagramas de despliegue
Explica cómo representar nodos, entornos, redes, procesos, réplicas, almacenamiento y dependencias para conectar software con su topología de ejecución.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo representar nodos, entornos, redes, procesos, réplicas, almacenamiento y dependencias para conectar software con su topología de ejecución.
Un diagrama de despliegue explica dónde se ejecuta el software, cómo se comunica, qué límites de fallo existen y qué infraestructura sostiene sus garantías operativas.
Mientras C4 Container muestra unidades ejecutables lógicas, la vista de despliegue ubica instancias concretas en nodos, redes, zonas, regiones y servicios gestionados.
Un diseño puede parecer correcto en código y fallar operacionalmente porque todos los componentes comparten un único nodo, una sola zona o una dependencia sin redundancia. El despliegue hace visibles disponibilidad, seguridad de red, escalado y recuperación.
software lógico
→ artefacto desplegable
→ instancia
→ nodo o servicio gestionado
→ zona/región
→ red y dependencias
→ límites de falloImagen, paquete, función o bundle versionado que se despliega.
Ejecución concreta del artefacto.
Máquina, VM, pod, dispositivo o entorno que ejecuta instancias.
Límites físicos o lógicos de fallo y latencia.
Segmentos, balanceadores, gateways, reglas y rutas.
Base, cola, almacenamiento o CDN operado por un proveedor.
flowchart TB
User[Usuarios] --> CDN[CDN / Edge]
CDN --> LB[Load Balancer]
subgraph Region[Región principal]
subgraph ZoneA[Zona A]
API1[API instance]
W1[Worker instance]
end
subgraph ZoneB[Zona B]
API2[API instance]
W2[Worker instance]
end
DB[(PostgreSQL primary + standby)]
Broker[(Managed broker)]
Object[(Object storage)]
end
LB --> API1
LB --> API2
API1 --> DB
API2 --> DB
API1 --> Broker
API2 --> Broker
W1 --> Broker
W2 --> Broker
W1 --> Object
W2 --> ObjectUna imagen reproducible debería:
Un contenedor comparte el kernel del host y no equivale a una VM.
Una instancia stateless puede reemplazarse sin perder estado durable. Esto facilita escalado y despliegue, pero no significa que el sistema completo carezca de estado.
Sesiones, archivos, locks y jobs deben ubicarse en servicios explícitos. Guardarlos en memoria local puede funcionar con una instancia y fallar al escalar.
Aumenta CPU, memoria o I/O por instancia. Es simple, pero tiene límites y puede ampliar el impacto de fallo.
Añade instancias. Requiere distribución de carga, coordinación y estado externo.
Puede basarse en CPU, memoria, concurrencia, latencia o lag. La métrica debe representar saturación real. Escalar por CPU no ayuda si el cuello está en conexiones de base o proveedor externo.
Una dependencia externa temporalmente caída no siempre debería marcar liveness como fallida y provocar reinicios en cascada.
Durante una terminación:
Sin graceful shutdown, despliegues normales producen errores y duplicados.
Reemplaza instancias gradualmente. Económico, pero versiones coexistirán.
Mantiene dos entornos y cambia tráfico. Facilita rollback, con mayor coste y atención a datos.
Expone una fracción a la nueva versión y observa métricas. Requiere segmentación y criterios automáticos.
Separa despliegue de activación. Introduce deuda si flags antiguos no se eliminan.
Ninguna estrategia resuelve migraciones incompatibles por sí sola.
Para añadir una columna obligatoria sin downtime:
El proceso debe tolerar coexistencia de versiones y rollback.
Documenta:
Un “backend privado” no es privado si cualquier workload de la red puede acceder sin autenticación.
Añadir instancias puede agotar conexiones a PostgreSQL. El despliegue debe considerar pools, límites por instancia y capacidad del downstream.
20 instancias × pool 20 = 400 conexionesEscalar una capa puede saturar otra.
Protege contra fallo de una zona cuando balanceo, datos y dependencias también están distribuidos.
Reduce impacto regional o latencia global, pero añade replicación, consistencia, routing, coste y operación. No se justifica automáticamente.
Rollback de código puede ser imposible si la migración de datos ya cambió semántica. El plan debe incluir compatibilidad hacia atrás, backups, restore probado y criterios de abortar.
Mide por versión:
Un canary sano técnicamente puede estar creando pedidos incorrectos; incluye señales funcionales.
Funciones o instancias nuevas pueden tardar en responder. Considera warming o presupuestos de latencia.
Puede seguir viva pero sin acceso a datos. Readiness y routing deben reaccionar.
Define leases, reanudación e idempotencia para que el worker pueda detenerse.
La nueva versión puede arrancar con secretos o variables faltantes. Valida configuración antes de recibir tráfico.
Productores y consumidores coexistirán; los contratos deben ser compatibles.
Una aplicación pequeña puede desplegarse en una plataforma gestionada con una región y servicios respaldados. Añadir multi-región o clusters complejos antes de conocer criticidad aumenta coste y superficie de fallo.
Datos, privacidad y seguridad desde el diseño aplica amenazas, minimización y controles sobre todos estos límites.