Llevamos varios años trabajando exclusivamente con scale-ups: empresas que ya validaron su modelo de negocio y están en la etapa de crecer. Y en esa etapa, los errores de arquitectura cloud tienen un costo real: en plata, en tiempo y en clientes que se van porque el sistema no aguanta.
Estos son los cinco errores que más veces hemos visto, con ejemplos concretos de cómo se manifiestan y qué hicimos para resolverlos.
Error 1: diseñar para el tráfico futuro imaginario
El más común. El equipo proyecta que en dos años van a tener un millón de usuarios, y diseñan la infraestructura para eso desde el día uno.
El resultado: un sistema sobre-engineered que cuesta el doble de lo necesario, que nadie entiende del todo, y que tiene capas de abstracción que solo añaden complejidad sin beneficio real.
Vi esto en una plataforma de e-commerce. Habían implementado una arquitectura event-driven completa con Kafka, múltiples colas de procesamiento, y un sistema de caché en tres niveles, todo para un catálogo de 5.000 productos y 200 usuarios activos diarios.
El costo mensual de infraestructura era de $4.000. Después de simplificar, bajó a $600 con la misma performance.
El principio correcto: diseñá para el tráfico de ahora + un 3x de margen. Cuando llegues al límite, escalar un sistema bien estructurado es mucho más fácil de lo que parece. Los cloud providers existen exactamente para eso.
Error 2: no usar managed services cuando deberían
“Podemos correr nuestra propia base de datos en EC2, es más barato”.
Tal vez sea más barato en el costo directo de infraestructura. Pero no cuenta el tiempo que va a pasar alguien gestionando backups, configurando réplicas, investigando problemas de performance, aplicando patches de seguridad, y perdiendo el sueño cuando hay un fallo de disco.
El tiempo de ingeniería es el recurso más escaso de una scale-up. Gastarlo en operar infraestructura que alguien más puede manejar mejor y más barato es una mala decisión de negocio.
RDS, Cloud SQL, PlanetScale, Supabase. Alguno de estos resuelve tu problema de base de datos y te deja enfocarte en lo que diferencia tu producto.
Lo mismo aplica para colas de mensajes, almacenamiento de archivos, autenticación, y caching. Hay managed services para casi todo. Usalos.
La excepción: cuando tenés requerimientos muy específicos que ningún managed service resuelve, o cuando el volumen es tan alto que el costo justifica la operación propia. Pero ese momento llega mucho más tarde de lo que la mayoría cree.
Error 3: observabilidad como afterthought
“Primero lanzamos, después agregamos logs y monitoreo”.
Este es el error que más caro se paga. Cuando algo falla en producción —y algo va a fallar— la capacidad de diagnosticar el problema rápido vale decenas de miles de dólares en tiempo perdido y usuarios afectados.
Tuvimos un cliente que tardó tres días en diagnosticar un problema de performance porque no tenía logs estructurados ni métricas. El problema terminó siendo una consulta N+1 que tardaba 40ms en staging y 4 segundos en producción por diferencia de volumen de datos. Con instrumentación básica, lo habríamos encontrado en 20 minutos.
Lo mínimo viable de observabilidad para una plataforma en producción:
- Logs estructurados (JSON, no texto plano) con contexto relevante: usuario, operación, duración.
- Métricas de aplicación: tiempo de respuesta por endpoint, tasa de errores, uso de recursos.
- Alertas básicas: cuando el error rate supera un umbral, cuando el tiempo de respuesta se degrada, cuando los recursos están al límite.
- Health checks: endpoints que verifican que la aplicación y sus dependencias están funcionando.
Con Datadog, Grafana Cloud o incluso CloudWatch bien configurado, podés tener todo esto en un día de trabajo.
Error 4: no pensar en los costos hasta que la factura llega
AWS, GCP y Azure son convenientes. También pueden ser sorprendentemente caros si no prestás atención.
Los patrones más comunes de costos descontrolados que vemos:
Datos egress: mover datos hacia afuera del cloud cuesta. Si tu arquitectura mueve mucha data entre regiones o hacia el cliente, ese costo se acumula rápido.
Instancias sin uso: entornos de staging, instancias de desarrollo, bases de datos de prueba que nadie apagó. He visto empresas pagando $800 por mes por instancias que nadie usa hace meses.
Sin reservas: las instancias on-demand son caras. Si sabés que vas a usar una capacidad determinada de forma consistente, las reserved instances o committed use discounts pueden reducir el costo a la mitad.
S3/GCS sin lifecycle policies: los archivos que se suben nunca se borran. Con el tiempo, el almacenamiento crece sin control.
La solución es simple: configurá un budget alert desde el primer día. Si la factura supera un umbral, recibís una notificación antes de que sea un problema. Y revisá los costos al menos una vez por mes.
Error 5: multi-región prematura
Tener infraestructura en múltiples regiones tiene sentido cuando tenés usuarios distribuidos geográficamente que se ven afectados por la latencia, o cuando tenés requerimientos de disponibilidad que justifican la complejidad y el costo.
La mayoría de las scale-ups no están en esa situación.
Multi-región significa: sincronización de datos entre regiones, gestión de failover, costos duplicados o triplicados, complejidad operacional significativa, y un sistema mucho más difícil de debuggear.
Vi una plataforma con 500 usuarios activos en una sola ciudad, corriendo en dos regiones de AWS “por disponibilidad”. El costo adicional era de $1.200 por mes. El tiempo que el equipo dedicaba a resolver problemas de sincronización de datos era de varias horas por semana.
La alternativa correcta: una sola región, bien configurada, con backups automáticos y un plan de recuperación claro. Para la mayoría de los casos de uso, el downtime de un incidente regional de AWS es menor al downtime que generan los errores de sincronización de datos en multi-región.
Cuando tengas usuarios reales que se quejen de latencia desde otra región, ese es el momento de pensar en multi-región.
El patrón que funciona
Lo que funciona para la mayoría de las scale-ups con las que trabajamos:
- Una región, bien elegida (la que está más cerca de tus usuarios).
- Managed services para base de datos, caché, cola de mensajes.
- Observabilidad desde el día uno: logs, métricas, alertas.
- Infraestructura como código (Terraform o Pulumi): reproducible, versionada, revisable.
- Budgets configurados desde el primer día.
- Arquitectura simple que pueda entender alguien que no estuvo en el proyecto desde el inicio.
Es menos glamoroso que una arquitectura distribuida sofisticada. También es lo que permite crecer de forma sostenible sin que la infraestructura sea un obstáculo.
Si querés revisar la arquitectura cloud de tu plataforma, hacemos este tipo de auditorías regularmente.