Arquitecturas cloud aburridas que sobreviven al crecimiento

El primer diagrama cloud de una startup parece un tablero de Pinterest. Seis servicios, dos colas, una Lambda llamada “magia”, un CDN que hace demasiado, y una página de Notion que lo explica. Seis meses después, el diagrama es el mismo — solo que ahora hay tres personas de guardia y un acuerdo tácito de no tocar la config del CDN.

El cloud aburrido es lo contrario. Es la arquitectura que puedes pasarle a un nuevo ingeniero senior y que sea productivo el día tres. Estas son las tres reglas a las que vuelvo siempre.

1. Una sola base de datos, hasta que duela

He perdido la cuenta de cuántas veces he visto a un equipo partir sus datos en tres bases de datos antes de tener tres clientes. “Postgres para usuarios, DynamoDB para eventos, Redis para sesiones” — escrito en una pizarra mientras todavía están en el tier gratuito.

Casi cualquier producto puede vivir en un único Postgres durante los primeros 18 meses de crecimiento. Postgres hace JSON, búsqueda full-text, series temporales por particiones, colas con SKIP LOCKED y búsqueda vectorial con pgvector. La contrapartida del monocultivo es menos carga cognitiva operativa, que es el recurso que se agota primero cuando un equipo crece.

Añade un segundo almacén cuando tengas un motivo medido: una query sostenida que el planner no salva, un patrón de escritura que rompe el vacuum, o una carga (full-text sobre decenas de millones de filas) que exige un motor especializado. Elige bien ese almacén. La idea no es no partir nunca — es partir con evidencias.

2. Cómputo sin estado, observado con estado

El cómputo debe ser reemplazable. Si un pod o contenedor mantiene estado — una caché, una sesión, un contador — es un incidente futuro. Empuja el estado a la base de datos (o a una caché dedicada tipo Redis), mantén el cómputo aburrido, y tu problema de escalado se convierte en “añade una réplica” en vez de “drena todo con cuidado”.

La cara opuesta: esos workloads reemplazables deben estar observados individualmente. Cada petición recibe un request id; cada job, un job id; cada span se enlaza con el usuario que lo disparó. Cuando algo explota a las 03:14, deberías poder leer el trace de una petición y saber qué línea de código fue. No inferir. Leer.

Un header traceparent propagado de extremo a extremo vale más que tres proveedores de monitoring.

3. La plataforma son sus fronteras

Lo interesante de una arquitectura no es lo que hay dentro — cada cloud tiene cómputo, almacenamiento, colas. Lo interesante son las fronteras que dibujas. ¿Dónde acaba la internet pública? ¿Dónde deja de poder fluir PII? ¿Qué servicios pueden llamar a qué otros servicios?

Las fronteras son baratas de codificar en IaC y caras de descubrir en mitad de un incidente. Codifícalas:

• Una única VPC con subnets que mapean niveles de confianza (público / app / datos).
• Un IAM principal por servicio, con la política más pequeña razonable.
• Salida por un único NAT o proxy, logueada.
• Secretos en un secrets manager, nunca en .env commiteados a nada.

La mayoría de historias de “la factura de AWS se disparó” en las que he aterrizado vienen de fronteras difusas. Un entorno de staging que llegaba a producción. Una Lambda con un rol heredado. Un bucket con una policy heredada.

---

Cloud aburrido no significa cloud pequeño. Significa un cloud cuyas sorpresas ocurren a propósito. Lo nuevo aterriza deliberadamente, el equipo entiende qué hay en producción, y el on-call rota en vez de acumularse en el calendario de una sola persona.

Esa es la arquitectura por la que merece la pena crecer.