Fuiste a una charla de tech, o viste un thread que se hizo viral, y ahora tenés una frase dando vueltas en la cabeza: "quiero que mi producto esté armado con microservicios desde el día uno". Es una frase totalmente razonable si trabajás en una empresa con cientos de developers repartidos en decenas de equipos. Es una frase carísima si tu equipo son tres o cuatro personas y todavía no lanzaste ni la primera versión del producto.
Esta es la conversación que tenemos con buena parte de los founders que nos llegan con esa idea ya instalada, casi siempre de una charla o un artículo que describía la arquitectura de una empresa que no se parece en nada a la tuya. Y no es que microservicios sea una arquitectura mala — es una herramienta que resuelve un problema muy específico, y ese problema, con altísima probabilidad, todavía no es el tuyo.
Qué es un monolito, en criollo
Un monolito es tu producto entero viviendo en una sola aplicación: el frontend, la lógica de negocio, la conexión a la base de datos, todo junto, en una sola base de código que se despliega como una unidad. Cuando hacés un cambio y corrés el deploy, se actualiza el producto completo de una vez.
No es sinónimo de arquitectura vieja ni de mala práctica, aunque la palabra "monolito" suene a piedra pesada difícil de mover. Es, lisa y llanamente, la forma más directa de construir software: todo en un mismo lugar, todo hablando entre sí dentro del mismo proceso sin necesidad de red de por medio, todo desplegado junto en cada actualización.
Qué son microservicios, en criollo
Microservicios divide ese mismo producto en piezas independientes: un servicio para pagos, otro para usuarios, otro para notificaciones, cada uno con su propio código, a veces su propia base de datos, y su propio ciclo de despliegue. En lugar de llamarse entre sí como funciones dentro del mismo programa, se comunican por red — HTTP, colas de mensajes — como si fueran aplicaciones separadas que conversan entre ellas.
La promesa es real: cada pieza se puede escalar, actualizar o hasta reescribir sin tocar las demás. El problema es que esa independencia no es gratis — se paga en infraestructura y en coordinación que antes no existían.
La comparación de un vistazo
| Monolito | Microservicios | |
|---|---|---|
| Velocidad para lanzar | Rápida — una sola app, un solo deploy | Lenta — hay que levantar y conectar varios servicios antes de tener algo andando |
| Costo de infraestructura | Bajo — un servidor o una instancia gestionada alcanza | Alto — cada servicio necesita su propio hosting, monitoreo y a veces su propia base de datos |
| Complejidad operativa | Baja — un solo log, un solo pipeline de deploy | Alta — orquestación, descubrimiento de servicios, versionado de contratos entre APIs |
| Cambiar de opinión sobre el producto | Fácil — mover lógica entre módulos es editar archivos | Difícil — cambiar cómo se relacionan dos servicios implica tocar contratos y despliegues de ambos |
| Cuándo escala mejor | Equipos chicos y medianos, cargas que no justifican separar | Equipos grandes trabajando en paralelo, o partes del sistema con necesidades de escala muy distintas entre sí |
El mito que hay que desarmar: "más profesional" no es una razón
Acá está el punto que más vale la pena aclarar: microservicios no es "más profesional" ni "mejor" en abstracto. Es una herramienta que existe para resolver dos problemas puntuales: equipos grandes que necesitan trabajar en paralelo sin pisarse el código todo el tiempo, y partes de un sistema con necesidades de escala tan distintas entre sí que conviene escalarlas por separado — un servicio de procesamiento de video que necesita 50 instancias mientras el resto del producto necesita 2, por ejemplo.
Si tu equipo tiene entre tres y ocho personas, ese primer problema —coordinar equipos grandes sin que se pisen— directamente no existe todavía. Estás usando una arquitectura pensada para un problema de otra escala, y ese desajuste se paga en tiempo y en plata, no en prestigio técnico.
Por qué arrancar un MVP con microservicios sale caro
Empezar un producto nuevo con microservicios casi siempre es un error caro, y no por prejuicio contra la arquitectura — es aritmética simple:
- Más tiempo de desarrollo. Cada llamada entre servicios necesita un contrato definido, manejo de errores de red, reintentos, versionado de APIs internas. Son semanas de trabajo de infraestructura antes de escribir la primera feature que el usuario va a ver.
- Más infraestructura para mantener. En vez de un deploy y un log, tenés varios servicios corriendo, cada uno con su propio monitoreo, sus propias alertas, su propio pipeline de CI/CD.
- Debugging más difícil. Un bug ya no está solamente "en el código" — puede estar en la comunicación entre dos servicios, en un timeout de red, en una versión desincronizada de un contrato. Encontrarlo toma más tiempo con un equipo chico y sin un área de DevOps dedicada.
- Todo esto para resolver un problema —coordinación entre equipos grandes— que un equipo de tres o cuatro personas directamente no tiene.
El resultado típico que vemos cuando un founder insiste con microservicios desde el día uno: meses extra de desarrollo, un costo de infraestructura mensual que no se justifica con la cantidad de usuarios reales que tiene el producto, y una fecha de lanzamiento mucho más lejana para validar si alguien lo quería usar en primer lugar.
El camino real: monolito bien organizado, separar solo cuando duela
La alternativa no es "monolito desordenado" contra "microservicios prolijos". Es un monolito modular: todo el producto vive en una sola aplicación, pero el código está organizado por dominio — una carpeta para pagos, otra para usuarios, otra para notificaciones — con límites claros entre cada módulo aunque compartan el mismo despliegue. Esto te da la mayor parte de la claridad organizativa de los microservicios, sin pagar el costo de operar varios sistemas distribuidos desde el día uno.
Ahí es donde arrancamos en prácticamente todos los MVPs que construimos en Cambalache Studio. La separación en microservicios llega después, cuando una pieza puntual del sistema realmente lo necesita: porque tiene una carga de tráfico completamente distinta al resto (un procesador de imágenes o de video, por ejemplo), porque se suma un equipo nuevo que necesita trabajar sobre esa pieza sin bloquear al resto, o porque un requisito técnico puntual —un lenguaje distinto, una necesidad de escala específica— lo justifica. En ese momento se extrae esa pieza a su propio servicio, con evidencia real de por qué hace falta, no porque "así se hace en las empresas grandes".
Conclusión
La pregunta no es cuál arquitectura es mejor — es cuál resuelve el problema que tenés hoy. Si tu equipo es chico y todavía estás validando que el producto tiene sentido, un monolito bien organizado por dominio te lleva a producción más rápido, más barato, y con menos partes móviles que puedan romperse. Los microservicios están para cuando el problema real —equipos grandes coordinándose, o partes del sistema con necesidades de escala muy distintas— aparece de verdad, no antes. Es la misma lógica que separa un MVP de un producto completo: usás la herramienta que corresponde a la etapa en la que estás, no la que suena mejor en una charla. Si además estás definiendo dónde alojar ese monolito y con qué backend, Vercel vs AWS es el siguiente paso lógico de esa decisión.