Cada vez que arranco un proyecto nuevo me hago la misma pregunta: ¿qué arquitectura es la correcta? La respuesta corta es depende. La respuesta útil es depende de cinco cosas concretas.
Este post no es dogma. Es un punto de partida para una buena conversación con tu yo del futuro.
Las cinco preguntas previas
Antes de elegir arquitectura, decido cinco cosas:
- ¿Hay lógica de negocio compleja, o es CRUD con pintura?
- ¿Cuántos equipos van a tocar el código en los próximos 12 meses?
- ¿Cuál es la latencia tolerable para una operación cualquiera?
- ¿Cuánto vivirá el proyecto realmente - MVP de 2 meses o producto a 5 años?
- ¿Qué tengo que poder cambiar sin reescribir - la BD, el LLM, el framework?
Las respuestas a estas cinco filtran el 90% de las arquitecturas. Lo que queda es la decisión.
Mapa rápido por tipo de proyecto
| Tipo de proyecto | Arquitectura | Evita |
|---|---|---|
| CRUD simple / admin panel | MVC en 3 capas | Hexagonal, microservicios |
| API con lógica de negocio media | Hexagonal | Microservicios prematuros |
| Dominio complejo, reglas de negocio profundas | Hexagonal + DDD | - |
| Múltiples equipos, alta escala | Microservicios | Sin experiencia en K8s |
| Procesamiento asíncrono / notificaciones | Event-driven | - |
| MVP / prototipo de validación | Monolito simple | Todo lo demás |
| API serverless / webhooks | Serverless (Lambda, Vercel Functions) | Procesos > 15 min |
Lo más importante de esta tabla no es la columna del medio. Es la columna "Evita".
Hexagonal: cuándo sí, cuándo no
Hexagonal (Ports & Adapters) te da algo concreto: el dominio testable sin BD, intercambiable de infra sin tocar lógica, equipos paralelos.
A cambio cuesta: boilerplate, curva de aprendizaje, más archivos que un CRUD simple.
Señales de over-engineering
Tres señales claras de que no necesitas Hexagonal:
- App CRUD sin lógica de negocio → MVC en 3 capas resuelve
- Equipo de menos de 3 personas sin experiencia previa en DDD → empieza con capas, migra cuando duela
- MVP fase 0 con menos de 2 meses de horizonte → demasiada infraestructura para validar la hipótesis
Cuándo sí
- Vas a tener varias UI (web + mobile + CLI) sobre el mismo dominio
- Vas a cambiar la BD a medio plazo y no quieres bloquear el desarrollo
- El dominio tiene reglas de negocio que sobreviven a UIs y storage
- Vas a testear la lógica sin levantar infraestructura (CI rápido, test-driven sostenible)
Microservicios: el patrón con peor relación riesgo/recompensa
Microservicios resuelven un problema muy concreto: escalar equipos, no escalar tráfico. Si tu cuello de botella es el tráfico, escalas el monolito horizontalmente y vives feliz. Si tu cuello de botella son los humanos pisándose en el mismo repo, microservicios empiezan a tener sentido.
El precio:
- Latencia añadida (cada llamada cruza red)
- Observabilidad obligatoria (sin tracing distribuido vuelas a ciegas)
- Coordinación de despliegues (versionado de APIs, contratos)
- Operaciones complejas (Kubernetes, service mesh, secrets compartidos)
Si no tienes equipo dedicado de plataforma, microservicios te van a costar tres veces más de lo que esperas.
Regla práctica: si la decisión es entre "monolito que escala mal" y "microservicios sin SRE", elige el monolito. Es más fácil partir un monolito sano que rehacer un microservicio mal hecho.
Event-driven: el patrón infravalorado
Event-driven es la respuesta correcta a más casos de los que la gente reconoce. Casos típicos:
- Notificaciones (email, push, slack, ws)
- Audit log de cambios
- Procesamiento batch desacoplado del request
- Integraciones con sistemas externos lentos
El truco está en que no tienes que adoptarlo todo o nada. Puedes meter una sola cola (BullMQ sobre Redis, SQS, Kafka) en una parte concreta del sistema y dejar el resto síncrono. La gente no lo hace porque el primer ejemplo que ven en internet es un sistema completo CQRS + Event Sourcing, y se asustan.
Bases de datos: el otro 50% de la decisión
La arquitectura sin la BD es una conversación incompleta. Mi heurística:
- PostgreSQL por defecto. Joins complejos, transacciones, JSON cuando hace falta, full-text decente. Cubre el 80% de proyectos de producto.
- Redis para lo efímero. Caché, sesiones, colas ligeras, rate limiting. Nunca como primary store.
- Qdrant o pgvector para embeddings. Si ya estoy en Postgres, pgvector. Si necesito escala vectorial seria, Qdrant.
- Firebase Firestore solo para apps móviles donde el sync en tiempo real entre dispositivos compensa el lock-in al ecosistema Google.
- MongoDB lo evito salvo que el modelo de datos sea genuinamente document-oriented y las queries no requieran joins. Es raro.
Cómo lo decido en 5 minutos
Cuando empiezo un proyecto:
- Escribo en una nota las cinco preguntas de arriba con respuestas concretas (no "depende").
- Tacho las arquitecturas que la primera mata. Casi nunca quedan más de dos.
- Pongo trade-offs de las que quedan en una columna pros / columna contras de tres líneas cada una.
- Elijo la más simple que cumple los requisitos del próximo año, no del próximo lustro.
- Documento la decisión con un ADR (
docs/decisions/0001-arquitectura.md) - incluyendo qué descartamos y por qué.
El ADR es lo más importante. Dentro de seis meses no vas a recordar por qué elegiste X - pero tu yo del futuro y cualquiera que herede el código sí necesita saberlo.
Lo que aprendí escribiendo esto
La mayoría de las malas decisiones de arquitectura no vienen de elegir "lo equivocado". Vienen de elegir algo correcto para un proyecto distinto al que estás haciendo. Hexagonal está bien, pero no para un script de migración. Microservicios funcionan, pero no para un MVP de fin de semana. Event-driven escala, pero no si tu single-point-of-failure es la cola.
La pregunta correcta no es "¿qué arquitectura es mejor?". Es "¿qué arquitectura encaja con el problema, el equipo y el horizonte que tengo delante?". Y esa pregunta solo la puedes responder tú.