Arquitectura básica en la nube
, a la izquierda otro conectando varias cajas chicas entre sí con líneas finas (rol dominio multitarea / redes), a la derecha un tercero señalando algo con gesto severo de advertencia (rol dominio vigilancia / buenas prácticas). Tema: leyes y principios de arquitectura distribuida.)
En la Unidad 2 vimos las dos capas técnicas que sostienen la nube (virtualización y containerización). En esta unidad subimos un nivel: ¿qué principios guían las decisiones de arquitectura cuando diseñamos para la nube? Vamos a ver tres leyes empíricas que, una y otra vez, predicen por qué los sistemas distribuidos funcionan o fracasan: la Ley de Conway, la Ley de Gall y el Principio CAP.
1. ¿Por qué leyes y no recetas?
A diferencia de la Unidad 2, acá no hay comandos para copiar. Las leyes que siguen son observaciones sobre cómo se comportan los sistemas distribuidos y las organizaciones que los construyen. Conocerlas no te dice qué elegir, te dice por qué tu elección va a salir bien o mal. Diseñar arquitectura cloud sin estas leyes es como diseñar un puente sin entender de física: a veces se aguanta, pero no sabés por qué.
La arquitectura cloud está moldeada por fuerzas que no son técnicas.
La idea de fondo
La forma de tu sistema distribuido depende tanto de cómo se organiza tu equipo (Conway) y de cómo evolucionó tu producto (Gall) como de las tecnologías que elijas. Y una vez en producción, la física de las redes te obliga a hacer trade-offs (CAP) que no podés evitar.
Las tres leyes
ConwayEl sistema reflejará la estructura de comunicación de quienes lo construyen.
GallLos sistemas complejos que funcionan evolucionaron desde sistemas simples que funcionaban.
CAPEn sistemas distribuidos, no podés tener consistencia, disponibilidad y tolerancia a particiones al mismo tiempo.
Para tener en cuenta
- Son observaciones empíricas, no teoremas matemáticos: hay matices y excepciones.
- Se complementan: violarlas raramente sale gratis a mediano plazo.
2. Ley de Conway
Enunciada por Melvin Conway en 1967, antes de que existiera "la nube". Conway era programador y notó un patrón inquietante: la arquitectura del software refleja la arquitectura social del equipo que lo construye.
"Las organizaciones que diseñan sistemas están condenadas a producir diseños que copian la estructura de comunicación de dichas organizaciones." — Melvin Conway, 1967
Por qué importa en la nube
La nube favorece sistemas distribuidos: microservicios, serverless, contenedores orquestados. Cada uno de esos componentes tiene un dueño humano. Si los humanos no se comunican de forma desacoplada, los componentes tampoco lo harán. Es por eso que dos empresas con la misma stack pueden terminar con arquitecturas radicalmente distintas.
Las consecuencias en cloud
Equipos aisladosArquitectura desacoplada, microservicios bien definidos.
Equipo único y grandeMonolito o sistema con acoplamiento fuerte.
Comunicación rígidaIntegraciones pesadas, contratos fijos, APIs poco evolutivas.
Para tener en cuenta
- La "Inverse Conway Maneuver": si querés cierta arquitectura, primero diseñá los equipos que la producirán.
- Conway aplica también a la cultura: un equipo que no confía entre sí va a construir contratos defensivos.
.)
Ejemplos de Conway en la nube
Los patrones más comunes que se ven en la práctica son cuatro. Cuando una empresa tiene equipos independientes para pagos, catálogo y usuarios, cada uno termina desplegando su propio servicio con la tecnología que mejor le sienta: pagos con AWS Lambda + API Gateway, catálogo con contenedores en EKS, usuarios con Firebase. El resultado es una arquitectura multi-cloud desacoplada, con escalado y despliegues independientes por servicio. En el otro extremo, un equipo único y grande que gestiona toda la aplicación produce un monolito en una VM. Tiene sentido organizacional —una sola reunión, una sola release— pero arrastra cuellos de botella en los deploys, escalado horizontal limitado y la fragilidad de que un bug en cualquier módulo tumba todo.
Cuando dos equipos necesitan integrarse pero la comunicación es rígida, la solución típica es una cola de mensajes (SNS/SQS, Pub/Sub) con un contrato fijo. Parece desacoplar, pero solo cambia el lugar del acoplamiento: ahora vive en el contrato del mensaje, y si un equipo lo cambia, el otro se rompe igual. Por último, cuando hay DevOps por producto —cada equipo construye, opera y monitorea su propio servicio de punta a punta— la tendencia natural es elegir servicios serverless (Lambda + DynamoDB) por equipo, con la mínima dependencia cruzada posible.
Si querés una arquitectura cloud determinada, diseñá primero la organización. Cambiar arquitectura es difícil; cambiar la estructura humana que la produce es todavía más difícil, pero es lo que sostiene el cambio técnico.
3. Ley de Gall
Enunciada por John Gall en 1975 (en Systemantics), es la ley que más arquitectos cloud ignoran y más caro pagan cuando lo hacen. Tiene tres formulaciones complementarias:
"Un sistema complejo que funciona invariablemente ha evolucionado a partir de un sistema simple que funcionaba." — John Gall, 1975
Los dos corolarios
Corolario AUn sistema complejo diseñado desde cero nunca funciona y no puede repararse para hacerlo funcionar: hay que empezar de nuevo desde un sistema simple.
Corolario BLos sistemas tienden a crecer en complejidad hasta superar la capacidad de sus diseñadores para manejarlos.
Por qué importa en la nube
La nube ofrece tantas piezas que es muy tentador armar la arquitectura "perfecta" desde el día 1: Kubernetes multi-región, service mesh, observabilidad completa, GitOps, etc. Gall predice qué va a pasar: el equipo se va a hundir operando esa complejidad antes de tener clientes que la justifiquen.
Para tener en cuenta
- "Simple primero" no significa "para siempre simple": es el punto de partida desde donde evolucionar.
- La complejidad debe responder a un problema real ya observado, no a uno anticipado.
.)
Caso: evolución natural de monolito a serverless
- Punto de partida. Una startup lanza un MVP: monolito en una VM (EC2 o equivalente), una base de datos. Funciona, pero el equipo no puede escalar features rápido.
- Primer dolor real. El módulo de autenticación bloquea releases del resto. Se extrae a un servicio serverless (Lambda + Cognito).
- Segundo dolor real. La base de datos no escala en picos. Migran a Aurora Serverless o una base gestionada similar.
- Tercer dolor real. El monolito sigue acoplando deploys. Recién ahora dividen el resto en microservicios sobre EKS.
- Resultado. Una arquitectura cloud-native compleja que funciona, porque cada paso resolvió un problema concreto y ya validado.
Anti-patrón: la arquitectura "perfecta" del día 1
Qué suele pasar
Un equipo arranca un proyecto chico y monta de entrada Kubernetes con service mesh (Istio), GitOps (ArgoCD), monitoreo completo (Prometheus + Grafana), múltiples namespaces y un esquema de roles RBAC sofisticado. Tres microservicios. Tres.
Por qué
Se confunde "estado final de empresas grandes" con "buena práctica". Se invierte tiempo en operar la infra en lugar de validar la idea del producto.
Cómo evitarlo
Empezá con servicios gestionados simples (App Engine, Fly.io, Render, ECS Fargate). Migrá a Kubernetes cuando el equipo sea grande, las cargas heterogéneas y la portabilidad un requisito, no antes.
Caso: una API que creció bien
- Fase 1 — API simple. API Gateway + Lambda. Sin estado, sin base de datos, sin observabilidad cara. Resuelve el caso de uso original.
- Fase 2 — persistencia. Aparece la necesidad real de guardar estado. Se agrega DynamoDB. Punto.
- Fase 3 — orquestación. Una operación pasa a tener 4 pasos coordinados con reintentos. Se incorpora Step Functions.
- Fase 4 — eventos asíncronos. Un equipo tercero necesita escuchar lo que pasa. Se publica a EventBridge.
Caso real ilustrativo: Netflix empezó con un monolito en sus propios data centers. Migró a AWS de a poco, no de un día para el otro, y construyó sus herramientas famosas (Chaos Monkey, Hystrix) para aprender a operar la complejidad emergente, no para evitarla por diseño previo.
4. Principio CAP
Formulado por Eric Brewer en 2000 (conjetura) y demostrado formalmente por Gilbert y Lynch en 2002, el teorema CAP es la ley física de los sistemas distribuidos. No describe una preferencia: describe un límite que no se puede superar.
En un sistema distribuido solo podés garantizar dos de tres: Consistencia, Disponibilidad y Tolerancia a particiones.
Las tres propiedades
C — ConsistenciaTodos los nodos ven los mismos datos al mismo tiempo.
A — DisponibilidadEl sistema responde siempre, incluso si hay fallos.
P — Partition toleranceEl sistema sigue funcionando aunque se pierda la comunicación entre nodos.
El verdadero dilema en la nube
En cloud, las particiones de red son inevitables: zonas de disponibilidad caídas, latencia variable, cables submarinos cortados. Por eso P no es opcional. El verdadero dilema se reduce a: ¿Consistencia (C) o Disponibilidad (A)?
Para tener en cuenta
- El trade-off no es siempre el mismo dentro de una misma app: la facturación pide CP, el feed social pide AP.
- "Consistencia eventual" no es ausencia de consistencia: es consistencia diferida en el tiempo.
; la pelota azul se le está escapando volando por el aire, gesto entusiasmado pero abrumado, bombita de luz encendida sobre la cabeza. Tema: en sistemas distribuidos no se pueden tener las tres propiedades a la vez (dominio multitarea / redes / distribución).)
¿Por qué CA es imposible en la nube?
Qué suele pasar
Un equipo diseña sobre una base distribuida asumiendo que "la red siempre va a estar". Cuando hay una partición real (un AZ se cae, latencia explota, cable submarino), el sistema entra en un estado indefinido: datos inconsistentes y no disponibles a la vez.
Por qué
Las particiones en cloud no son una rareza: son una certeza estadística. Cualquier proveedor serio mide su SLA en porcentajes que presuponen particiones.
Cómo evitarlo
Asumí siempre que P es obligatorio. Decidí explícitamente C o A para cada componente, y documentá ese trade-off.
CP vs AP: cuándo elegir cada uno
El sistema prefiere rechazar operaciones antes que devolver datos inconsistentes. Si hay partición, los nodos del lado "minoritario" no aceptan escrituras.
Cuándo conviene
Cuando la exactitud importa más que la disponibilidad: pagos, facturación, inventario, historia clínica.
Ejemplos típicos
Ejemplo real
- Un banco no permite confirmar una transferencia si no puede verificar el saldo en todas las réplicas: prefiere "intentar más tarde" antes que duplicar el dinero.
El sistema prefiere responder siempre, aceptando que algunos clientes vean datos temporalmente desactualizados. La consistencia se alcanza después (consistencia eventual).
Cuándo conviene
Cuando la disponibilidad importa más que la exactitud inmediata: redes sociales, feeds, catálogos, recomendaciones, IoT.
Ejemplos típicos
Ejemplo real
- El carrito de compras de Amazon mantiene "agregar al carrito" disponible incluso ante fallos parciales: prefiere consolidar carritos divergentes después antes que perder una venta.
CP vs AP en producción
CP
- Datos siempre exactos.
- Razonamiento simple para el desarrollador.
- El sistema deja de responder durante particiones.
- Latencia más alta (consenso entre nodos).
AP
- Responde siempre, baja latencia.
- Escala globalmente sin coordinar.
- Los datos pueden divergir temporalmente.
- La aplicación debe manejar conflictos (last-write-wins, CRDTs, etc.).
Perfil CAP de algunos servicios cloud comunes
En el bando CP están servicios que prefieren bloquear escrituras antes que devolver datos inconsistentes: Amazon RDS con réplica síncrona, y Google Cloud Spanner, que garantiza consistencia global usando relojes atómicos al precio de rechazar escrituras en particiones graves. Del lado AP, Amazon DynamoDB ofrece consistencia eventual por defecto (con lecturas fuertemente consistentes opcionales a mayor costo), y Redis Cluster permite que los datos diverjan temporalmente entre shards. Azure Cosmos DB es un caso aparte: expone cinco niveles de consistencia configurables, dejando que el desarrollador elija dónde sentarse entre CP estricto y AP puro según el caso.
Ejemplo de uso mixto bien hecho: Netflix usa DynamoDB (AP) para su catálogo —donde lo que importa es responder rápido aunque un título tarde en propagarse— y Aurora (CP) para su facturación, donde una inconsistencia es inaceptable.
PACELC: la extensión moderna de CAP
Una crítica frecuente a CAP es que solo describe qué pasa cuando hay partición. PACELC, formulado por Daniel Abadi en 2010, completa la imagen: si hay partición (P), elegí entre A y C —ese es el caso original de CAP—; else (en operación normal, sin partición), elegí entre L (latencia) y C (consistencia). La idea es que incluso cuando la red anda bien, mantener consistencia entre nodos cuesta tiempo: sincronizar réplicas suma latencia, y muchos sistemas aceptan consistencia eventual también en estado normal para responder más rápido. DynamoDB, por ejemplo, es PA/EL: ante partición prioriza disponibilidad, y en operación normal prioriza latencia sobre consistencia estricta. Spanner es PC/EC: consistencia estricta en ambos casos, al precio de mayor latencia.
Si querés el espectro completo de productos por proveedor —tanto del lado relacional como NoSQL— y cuándo conviene cada perfil, ver el recurso database. Para los almacenes en memoria que aparecen del lado AP cuando hace falta velocidad sobre consistencia, ver el recurso cache. Y para desacoplar productores y consumidores aceptando consistencia eventual a propósito —la herramienta clave para construir sistemas AP sin perder operaciones—, ver el recurso colas de mensajes.
5. Cómo se conectan las tres leyes
Conway moldea la forma, Gall regula el ritmo, CAP define los límites.
Una historia que combina las tres
Una startup con un equipo único (Conway → monolito) lanza un MVP en una VM (Gall → empezar simple). Funciona. Al crecer, divide el equipo en pagos, catálogo y usuarios (Conway → microservicios). Cuando cada servicio se vuelve distribuido, el equipo descubre que necesita elegir entre CP (pagos) y AP (catálogo) por separado (CAP → no se puede tener las dos cosas a la vez).
Lectura combinada
- Conway te dice qué arquitectura va a salir de tu equipo actual.
- Gall te dice por dónde empezar y cómo crecer sin morir en el intento.
- CAP te dice qué trade-offs no podés esquivar una vez que el sistema vive en la nube.
6. Errores comunes derivados
Qué suele pasar
Se decide "vamos a microservicios" sin reorganizar al equipo. Resultado: microservicios artificialmente acoplados, donde cada cambio requiere reunir a cuatro personas distintas que antes estaban en la misma sala.
Cómo evitarlo
Antes de cambiar la arquitectura, cambiá la estructura de los equipos. Si no es viable cambiarla, ajustá la arquitectura a la organización real.
Qué suele pasar
Se invierte 3 meses en montar service mesh, observabilidad y CI/CD avanzado antes de tener una sola línea de producto funcionando. Cuando finalmente se construye el producto, los requerimientos ya cambiaron y la "arquitectura perfecta" no encaja.
Cómo evitarlo
Aplicá Gall: lo mínimo que funcione hoy, expandilo cuando aparezca un dolor real medible.
Qué suele pasar
Se usa la misma base de datos relacional con réplicas síncronas para todo, incluyendo módulos donde una consistencia eventual sería suficiente. Los costos explotan, la latencia sube y el throughput cae.
Cómo evitarlo
Aplicá CAP por componente: identificá qué módulos pueden ser AP y reservá CP para los que realmente lo necesitan.
7. Tips y buenas prácticas
Inverse Conway Maneuver: si querés llegar a microservicios, reorganizá los equipos primero en "células" autónomas cross-funcionales. La arquitectura va a seguir.
Documentá el trade-off CAP por componente: en el README de cada servicio, dejá explícito si es CP o AP y por qué. Evita debates eternos en code reviews.
Diseñá para el fallo, no contra el fallo. Las particiones, los timeouts y los nodos muertos no son excepciones: son la realidad operacional. Probá tu sistema con Chaos Engineering desde temprano.
8. Glosario rápido
9. Para profundizar
Melvin Conway · 1968 · lectura ~30 min
El artículo original donde Conway formula su ley. Vale la pena leerlo: es corto, claro y sorprendentemente vigente medio siglo después.
Ir al recursoJohn Gall · 1975 · libro corto y satírico
El libro de cabecera de Gall. Mezcla teoría de sistemas con humor seco. No es sobre software: es sobre por qué cualquier sistema complejo falla. Imprescindible.
Eric Brewer · 2012 · lectura ~20 min
Brewer revisita su propia conjetura 12 años después y matiza los malentendidos comunes ("CAP no significa elegir 2 de 3 de forma binaria"). Lectura obligatoria si vas a hablar de CAP en serio.
Ir al recursoMatthew Skelton, Manuel Pais · 2019 · libro
La aplicación moderna de la Ley de Conway. Propone cuatro tipos de equipos y tres modos de interacción para diseñar organizaciones que produzcan arquitecturas sanas.
10. Cierre
La arquitectura cloud no se elige: se descubre. Lo que podés hacer es no luchar contra las leyes que la moldean.
Qué hay que llevarse
Conway, Gall y CAP no son ideas opuestas a las herramientas que vimos en las unidades anteriores: son los filtros con los que conviene mirarlas. Antes de elegir Kubernetes, preguntate qué dice Conway sobre tu equipo y qué dice Gall sobre la madurez de tu producto. Antes de elegir una base de datos, preguntate qué dice CAP sobre los trade-offs que vas a asumir.
Qué viene
Unidad 4Metodologías ágiles y ciclo de vida del software: el proceso humano que produce sistemas que respetan (o ignoran) estas leyes.
Unidad 5IA generativa y cómo se integra al stack cloud moderno.
Unidad 6Aplicaciones concretas: el catálogo de piezas con las que se arma un producto real.
Antes de seguir
- Podés enunciar las tres leyes con tus palabras, sin mirar el material.
- Identificás, en un sistema que conozcas, una decisión que respeta cada una de las tres leyes.
- Identificás también una decisión que las viola, y entendés por qué duele.