Tu MVP no necesita microservicios: guía de un director técnico para dimensionar adecuadamente la arquitectura
Kubernetes, microservicios, event sourcing, CQRS. Tu MVP no necesita nada de eso. A continuación te explicamos cómo elegir la arquitectura adecuada para tu fase, evitar una ingeniería excesiva y lanzar el producto al mercado.
La epidemia de la ingeniería excesiva
En los últimos tres años hemos auditado el código fuente de más de 30 startups. El patrón más habitual: una arquitectura diseñada para 10 millones de usuarios, pero que solo da servicio a 500.
Una startup que aún no genera ingresos, con un clúster de Kubernetes, 12 microservicios, una cola de mensajes, una malla de servicios y una factura de infraestructura de 3000 dólares al mes. ¿Su competidor? Una aplicación monolítica de Django en un servidor de 50 dólares al mes, que lanza nuevas funciones cuatro veces más rápido.
La sobredimensionación no solo supone un derroche de dinero. También desperdicia el único recurso que las startups no pueden comprar: el tiempo.
Arquitectura por fases: lo que realmente necesitas
| Escenario | Usuarios | Arquitectura | Coste mensual de infraestructura |
|---|---|---|---|
| MVP / Validación | 0-1 000 | Monolith + base de datos gestionada | 20-100 dólares |
| Crecimiento tras el PMF | 1 000-50 000 | Monolith + caché + CDN | 100-500 dólares |
| Escalado | 50 000-500 000 | Monolito modular + trabajadores asíncronos | 500-3000 dólares |
| A escala empresarial | Más de 500 000 | Microservicios selectivos | Más de 3.000 dólares |
El monolito que hace más de lo que crees
Instagram prestaba servicio a 300 millones de usuarios mediante una arquitectura monolítica basada en Django. Shopify funciona con una arquitectura monolítica basada en Rails. Stack Overflow atiende a 100 millones de visitantes al mes mediante una arquitectura monolítica basada en .NET en nueve servidores web.
Una aplicación monolítica bien diseñada con PostgreSQL y Redis gestiona más tráfico del que el 99 % de las startups llegarán a tener jamás. El cuello de botella no es tu arquitectura, sino tus consultas a la base de datos, tus problemas N+1 y la falta de una capa de caché.
El momento adecuado para romper el monolito
Extrae un servicio cuando notes el problema, no antes:
1. Dificultades derivadas del crecimiento del equipo. Si hay más de diez desarrolladores trabajando al mismo tiempo en el mismo código, tiene sentido dividirlo en dos o tres servicios con responsabilidades claras.
2. Dependencia de implementación. Si la implementación del sistema de notificaciones requiere implementar toda la aplicación y ejecutar todas las pruebas, separa las notificaciones en un servicio independiente.
3. Diferentes necesidades de escalabilidad. Si el procesamiento de imágenes requiere 10 veces más potencia de cálculo que tu API, separarlo te permite escalar cada uno de forma independiente.
4. Ritmos de lanzamiento diferentes. Si el equipo de facturación realiza lanzamientos semanales, pero el producto principal lo hace a diario, contar con servicios independientes permite que cada equipo trabaje a su propio ritmo.
Si hoy en día ninguna de estas situaciones se aplica a tu caso, no necesitas microservicios. Y punto.
El conjunto de tecnologías que recomendamos en 2026
Tras haber creado más de 65 productos, esta es nuestra recomendación habitual para un MVP:
| Capa | Elección | ¿Por qué? |
|---|---|---|
| Servidor | Django o Node.js | Desarrollo rápido, un ecosistema enorme, probado en la práctica |
| Interfaz de usuario | Next.js (React) | SEO, SSR, excelente experiencia para los desarrolladores |
| Base de datos | PostgreSQL | Gestiona JSON, búsquedas de texto completo y datos relacionales en una sola base de datos |
| Caché | Redis (añadir cuando sea necesario) | Sesiones, limitación de velocidad, almacenamiento en caché de consultas costosas |
| Alojamiento web | VPS individual o Ferrocarril/Render | Entre 20 y 50 $ al mes, se implementa en cuestión de minutos |
| Almacenamiento de archivos | S3 o equivalente | No guardes archivos en el servidor |
| CI/CD | GitHub Actions | Gratis para la mayoría de las empresas emergentes |
Esta pila gestiona 100 000 usuarios al mes, cuesta menos de 100 dólares al mes y puede ser mantenida por un solo desarrollador. Cuando sea necesario ampliarla, todos los componentes se pueden actualizar sin necesidad de reescribirlos.
Lo que realmente buscan los inversores (Pista: no es Kubernetes)
En las más de 50 reuniones de diligencia debida en las que hemos prestado apoyo, los inversores nunca preguntaron: «¿Utilizan microservicios?». Lo que preguntaron fue:
1. ¿Con qué rapidez puedes implementar una nueva función? (Velocidad)
2. ¿Qué pasaría si tu desarrollador principal dejara la empresa? (Factor de riesgo)
3. ¿Es capaz la arquitectura de soportar 10 veces tu carga actual? (No 1000 veces, solo 10 veces)
4. ¿Disponen de pruebas automatizadas y de CI/CD? (Calidad)
Una arquitectura monolítica bien probada con CI/CD obtiene mejores resultados en todos los aspectos que una arquitectura de microservicios mal probada que solo una persona entiende.
La optimización prematura es la raíz de todos los males en la programación. La arquitectura prematura es la raíz de todos los males en las startups.
— alokknight Engineering, adaptado de Donald Knuth