¿El tamaño importa?

Al inicio de mi carrera todo lo resolvía con un VPS. Unos años después estaba convencido de que cualquier proyecto serio necesitaba microservicios, multi-tenancy y un orquestador. Hoy, con más cicatrices encima, volví al VPS. Y no, no es una regresión: es la curva completa.

El meme de la portada resume esa curva mejor que cualquier libro de arquitectura: he sido los tres personajes. Y como sugiere el título: sí, el tamaño importa. Pero no como yo creía al inicio.

Etapa 1: Todo cabe en un VPS sabiéndolo acomodar

Al inicio de mi carrera me tocó construir un sistema de medición IoT. Sensores mandando lecturas constantemente, datos que había que recibir, almacenar, procesar y graficar. ¿Mi solución? Todo en un VPS. Ingesta, base de datos, procesamiento, dashboard… todo conviviendo en la misma máquina.

No es que hubiera evaluado alternativas y decidido que un VPS era suficiente. Es que ni siquiera me hice la pregunta. Mi único criterio era "que funcione", y para un sistema que recibe telemetría continua —donde la ingesta puede crecer, los picos no avisan y perder datos sí duele— ese criterio se queda corto. No era la herramienta equivocada por ser un VPS; era la decisión equivocada porque no hubo decisión.

Estaba a la izquierda de la curva, estaba feliz porque no porque elegí bien. Estaba feliz porque no sabía qué está eligiendo.

Etapa 2: ¡NOOO, necesito web scale!

Con los años vinieron las lecturas, los cursos, las conferencias. Aprendí sobre microservicios, multi-tenancy, contenedores, orquestación. Y en mis ansias de aplicar las "mejores prácticas", me convertí en el personaje del centro de la curva.

El proyecto: un ERP para industria. Lo diseñé multi-tenant, lo partí en microservicios y lo monté sobre ECS. Sonaba a arquitectura seria, de las que salen en los diagramas de re:Invent.

¿La realidad hoy? Una sola empresa activa. Eso sí, con más de mil usuarios —no es un juguete—, pero al final del día es un ERP: cargas predecibles, crecimiento gradual y cero necesidad de escalar a millones de la noche a la mañana.

Y aquí viene lo interesante: el golpe no llegó por donde esperaba. La factura de AWS no fue el problema —no gastamos tanto—. El costo real fue operativo: somos un equipo pequeño manteniendo varios microservicios, cada uno con una tecnología distinta. Cambiar de contexto entre servicios confunde, el onboarding se alarga, y cada pieza extra es una pieza más que puede fallar a las 3 de la mañana.

La sobreingeniería no siempre se cobra en dinero. Casi siempre se cobra en mantenimiento y en carga cognitiva del equipo.

Etapa 3: El monje encapuchado (con un truco bajo la manga)

Hace poco llegó un nuevo proyecto: un sistema de reservas para estancias. Empezamos pequeño, con pocos usuarios y demanda modesta. ¿Y saben qué elegí? Un VPS.

Pero esta vez la decisión fue distinta, aunque la respuesta parezca la misma del inicio. No metí todo directo a la máquina: la aplicación corre en contenedores detrás de un nginx. Hoy eso no me da "web scale" —y no lo necesito—. Lo que sí me da son costuras: si mañana el negocio crece, mover esos contenedores detrás de un ALB, a un cluster o a un servicio administrado es una evolución, no una reescritura.

Esa es la diferencia de estar en la izquiera o la derecha de la curva. Los dos dicen "just use a VPS", pero uno lo dice por ignorancia y el otro por criterio. La herramienta es idéntica; la intención no.

El criterio práctico: cómo dimensionar

Después de recorrer la curva completa, mi criterio para dimensionar se resume en cuatro ideas.

**Dimensiona para el presente real, no para el futuro imaginario. **El tráfico que tienes hoy y el que razonablemente tendrás en seis meses son datos; los millones de usuarios "que podrían llegar" son ficción. Y diseñar para ficción tiene costos reales.

**Diseña las costuras, no el edificio completo. **No necesitas el cluster hoy, pero sí necesitas que llegar al cluster mañana no implique reescribir. Contenedores, un proxy al frente, configuración fuera del código, estado bien delimitado: eso es barato hoy y vale oro después.

**Cuenta el costo en carga cognitiva, no solo en factura. **Cada servicio, cada tecnología y cada capa que agregas la tiene que entender, operar y despertarse a arreglar alguien de tu equipo. Si tu arquitectura es más grande que tu equipo, el problema no es técnico.

**Cuando el sistema crezca, deja que la ingeniería crezca con él. **Subdimensionar tampoco es virtud: quedarse en el VPS cuando el negocio ya pide más es tan costoso como el web scale prematuro. El tamaño correcto es un blanco móvil, y revisarlo es parte del trabajo.

Ni tan chico que te ahorque, ni tan grande que te ahogue

Entonces, ¿el tamaño importa? Sí. La madurez en arquitectura no está en conocer las herramientas más avanzadas, sino en saber cuándo no usarlas —y en dejar la puerta abierta para el día que sí hagan falta—.

¿Y tú? ¿En qué punto de la curva estás: el junior feliz, el que llora por web scale, o ya te pusiste la capucha?