Arquitectura de Microservicios — Cuándo Usarla y Cuándo No

Introducción

La arquitectura de microservicios estructura una aplicación como una colección de servicios débilmente acoplados, cada uno propiedad de un equipo pequeño y desplegable de forma independiente. Resuelve problemas de escalamiento organizacional y técnico, pero introduce complejidad operativa significativa. Esta guía te ayuda a decidir cuándo el trade-off vale la pena.

¿Qué Son los Microservicios?

Un microservicio es una unidad de funcionalidad autónoma que:

• Posee sus datos — cada servicio tiene su propia base de datos, sin esquemas compartidos
• Es desplegable de forma independiente — un cambio en un servicio no requiere redeploy de otros
• Se comunica por red — vía HTTP/gRPC o mensajería asíncrona
• Es propiedad de un equipo pequeño — típicamente 5-15 ingenieros por servicio

Cuándo Usar Microservicios

Señal	Por Qué los Microservicios Ayudan
Múltiples equipos > 20 ingenieros	Reduce la sobrecarga de coordinación; equipos despliegan de forma independiente
Diferentes partes escalan de forma diferente	Escala solo el servicio caliente, no todo el monolito
Diferentes requerimientos tecnológicos	Un servicio necesita GPU, otro alta I/O — usa la herramienta correcta
Necesidad de cadencia de release independiente	La API móvil se despliega diariamente, el servicio de facturación mensualmente
Aislamiento de fallos requerido	Un bug en búsqueda no debe caer pagos

Cuándo NO Usar Microservicios

Señal	Alternativa Mejor
< 10 ingenieros	Monolito con límites de código modulares
Producto no probado / MVP	Monolito — itera más rápido, divide después
Bajo tráfico / dominio simple	Monolito — más simple de operar
Sin cultura DevOps/SRE	Monolito — los microservicios requieren prácticas operativas maduras
Requerimientos de latencia estrictos (< 10ms)	Monolito — los saltos de red agregan latencia

La Regla del Monolito Primero

Comienza con un monolito bien modularizado. Extrae servicios solo cuando un límite claro sea doloroso de mantener.

Tanto Martin Fowler como Sam Newman abogan por comenzar con un monolito y descomponer solo cuando el dolor es real. La descomposición prematura crea monolitos distribuidos — lo peor de ambos mundos.

Estrategias de Descomposición

1. Descomponer por Capacidad de Negocio

Servicio	Capacidad de Negocio
Servicio de Usuarios	Gestión de cuentas, autenticación
Servicio de Catálogo	Listados de productos, búsqueda, inventario
Servicio de Órdenes	Checkout, historial de órdenes, cumplimiento
Servicio de Pagos	Cargos a tarjetas, reembolsos, facturación
Servicio de Notificaciones	Emails, SMS, notificaciones push

Por qué funciona: los límites se alinean con cómo piensa y evoluciona el negocio.

2. Descomponer por Subdominio (DDD)

Usa contextos delimitados de Domain-Driven Design.

3. Patrón de la Higuera Estranguladora

Reemplaza gradualmente la funcionalidad del monolito con nuevos servicios.

Patrones de Comunicación

Síncrono (REST/gRPC)

Mejor para: consultas en tiempo real, request/response simple

Trade-off: Crea acoplamiento temporal. Si el servicio de Usuarios cae, el servicio de Catálogo se degrada.

Asíncrono (Event-driven)

Mejor para: trabajo en background, alto throughput, desacoplamiento

Trade-off: Consistencia eventual. Debugging es más difícil porque la ejecución no es lineal.

Propiedad de Datos y Consistencia

Base de Datos por Servicio

Nunca compartas una base de datos entre servicios. Crea acoplamiento oculto.

Manejando Necesidades de Datos Cruzados

• Composición de API: consulta ambos servicios y une en el cliente
• CQRS + Modelos de Lectura: desnormaliza datos vía eventos en un store local optimizado para lectura
• Patrón Saga: coordina transacciones distribuidas usando transacciones compensatorias

Patrones Comunes

Patrón	Problema que Resuelve
API Gateway	Punto de entrada único, routing, auth, rate limiting
Service Discovery	Encontrar instancias de servicios sin IPs hardcodeadas
Circuit Breaker	Fallar rápido cuando servicios downstream están unhealthy
Bulkhead	Aislar thread pools para prevenir fallos en cascada
Saga	Manejar transacciones distribuidas entre servicios
CQRS	Separar modelos de lectura y escritura para performance

Mejores Prácticas

• Posee el ciclo de vida completo — los equipos construyen, operan y soportan sus servicios
• Diseña para el fallo — asume que cualquier dependencia puede fallar
• Automatiza todo — si un deploy o rollback requiere un runbook, automatízalo
• Estandariza observabilidad — cada servicio debe emitir logs, métricas y trazas consistentes
• Limita dependencias entre servicios — evita cadenas profundas; prefiere fan-out sobre árboles profundos

Errores Comunes

• Crear demasiados servicios muy temprano — 5 servicios para 3 ingenieros es exceso
• Compartir bases de datos entre servicios — esto es un monolito distribuido
• Ignorar latencia de red — cada llamada síncrona es un potencial timeout o retry storm
• Subestimar costo operativo — los microservicios necesitan prácticas DevOps maduras
• Construir un framework RPC custom — usa estándares probados

Preguntas Frecuentes

¿Debería toda startup comenzar con microservicios?

No. Comienza con un monolito. Extrae servicios cuando un módulo sea doloroso de desplegar, escalar o razonar de forma independiente. La descomposición prematura es una causa común de ralentización de ingeniería.

¿Qué tan grande debería ser un microservicio?

Lo suficientemente pequeño para ser reescrito en 2-4 semanas. Si un servicio requiere 6+ ingenieros y meses para refactorizar, probablemente son múltiples servicios en disfraz. El “micro” se refiere al tamaño del equipo y alcance, no a líneas de código.

¿Cuál es el mayor riesgo de los microservicios?

Complejidad distribuida. Debuggear, probar y razonar sobre un sistema que abarca docenas de servicios es significativamente más difícil que un monolito. Sin observabilidad y automatización fuertes, la arquitectura te ralentizará en lugar de acelerarte.