Cuándo dividir, cómo conectar y qué patrones usar para no crear un monolito distribuido.
Hace un tiempo me tocó trabajar en un proyecto donde todo funcionaba. Un monolito. Un deploy, un repo, un equipo. Respondía rápido, los usuarios estaban contentos, el jefe estaba contento.
Hasta que alguien en una conferencia dijo: "los microservicios son el futuro".
Y miramos nuestro monolito y pensamos: "esto no escala, necesitamos microservicios".
Tres meses después teníamos 15 servicios. Un request del usuario pasaba por 7 de ellos antes de responder. Si inventario iba lento, el checkout se caía. Si notificaciones fallaba, nadie sabía por qué el pedido se quedó a medias.
Teníamos un monolito distribuido. Los mismos problemas de antes, pero ahora con latencia de red y 12 dashboards que nadie entendía.
La complejidad no desapareció. Solo cambió de forma.
Si alguna vez sentiste que migrar a microservicios iba a resolver todos tus problemas y terminó creando nuevos... este artículo es para ti.
¿Realmente necesitas microservicios?
Antes de hablar de cómo, hablemos de cuándo. Porque la decisión más inteligente a veces es no dividir.
Cuando empecé a investigar más sobre el tema, me di cuenta de que muchas migraciones a microservicios no nacen de un problema real. Nacen del hype. De escuchar que "Netflix usa microservicios" y asumir que nosotros también deberíamos.
Pero Netflix llegó a microservicios después de años de crecimiento y con miles de ingenieros dedicados a esa transición. El contexto importa: lo que funciona para una empresa con esa escala no necesariamente aplica para todos los equipos.
Señales reales vs. falsas alarmas
| ✅ Señales reales para dividir | ❌ Falsas alarmas |
|---|---|
| Equipos se bloquean entre sí para hacer deploy | "Netflix usa microservicios" |
| Un componente necesita escalar 100x más que el resto | "Mi monolito es legacy" |
| Dominios de negocio claramente independientes | "Quiero usar tecnologías diferentes por servicio" |
| Ciclos de release muy diferentes entre componentes | "Los microservicios son más modernos" |
| Un fallo en un módulo tumba todo el sistema | "Mi equipo de 3 personas necesita agilidad" |
Si tu equipo es pequeño y todo cabe en un deploy, no necesitas microservicios. Necesitas un monolito bien estructurado.
Divide cuando el dolor es real: equipos que se bloquean, componentes que necesitan escalar de forma radicalmente diferente, dominios de negocio que evolucionan a ritmos distintos.
No dividas porque suena moderno.
No es binario — hay un espectro
Algo que me costó entender al principio es que no es "monolito o microservicios". Hay un espectro completo entre ambos:
La mayoría de los sistemas no necesitan ir directo a microservicios.
Empieza con un monolito modular: un solo deploy, pero con límites claros entre dominios. Cuando un módulo necesite escalar o evolucionar independientemente, lo extraes.
Eso es escalar inteligente: dividir cuando hay evidencia, no cuando hay hype.
Serverless cambia las reglas
Cuando trabajas con microservicios tradicionales, cada servicio necesita su servidor, su scaling, su service discovery. Es mucha carga operativa.
Serverless cambia eso por completo:
| Microservicios Tradicionales | Microservicios Serverless |
|---|---|
| Tú manejas servidores por servicio | Sin servidores que gestionar |
| Tú configuras auto-scaling | Escala automática por función |
| Pagas por servidor encendido | Pagas por ejecución |
| Tú manejas service discovery | Eventos y colas conectan servicios |
| Kubernetes, Docker, load balancers | Lambda, API Gateway, EventBridge |
Pero hay algo que quiero dejar claro porque es una confusión muy común:
Un microservicio serverless no es UNA Lambda.
Es la colección de Lambdas detrás de un API Gateway que resuelven un dominio de negocio. Pedidos, inventario, pagos, cada uno es un microservicio compuesto por varias funciones pequeñas y enfocadas.
Si metes toda la lógica en una sola Lambda gigante, estás creando un monolito dentro de una función.
La pregunta ya no es "cómo escalo este servicio" sino "cómo conecto estos servicios de forma inteligente".
Y ahí es donde entran los patrones.
Los 3 patrones clave
Después de haber pasado por varias migraciones (algunas exitosas, otras no tanto), identifiqué tres patrones que marcan la diferencia entre una arquitectura de microservicios que funciona y un monolito distribuido disfrazado.
Los presento aquí a nivel conceptual. Cada uno tendrá su artículo dedicado con implementación práctica y código real.
Patrón 1: Comunicación desacoplada — eventos, no llamadas directas
Este fue el error que más me costó entender.
Cuando empezamos a dividir servicios, lo primero que hicimos fue conectar Lambdas en cadena. Lambda A llama a B, B llama a C. Parecía lógico.
El problema:
Si C falla, todo falla. Las latencias se suman. Estás recreando el monolito pero con más latencia.
El patrón correcto es usar eventos asíncronos:
Tu microservicio responde al usuario y emite un evento. Los demás microservicios reaccionan al evento a su propio ritmo.
Desacoplados. Independientes. Resilientes.
Amazon EventBridge actúa como un bus de eventos serverless que desacopla la lógica de enrutamiento de tus microservicios. Amazon SQS te da colas de mensajes para procesamiento asíncrono con garantías de entrega. Ambos son piezas fundamentales para este patrón.
En el próximo artículo de la serie vamos a implementar este patrón paso a paso con EventBridge y SQS, incluyendo las trampas que te puedes encontrar.
Patrón 2: Cada servicio, su data
Este es directo y no tiene vuelta:
Si todos tus servicios leen y escriben en la misma tabla de DynamoDB, no tienes microservicios. Tienes un monolito disfrazado.
El patrón correcto:
Cada servicio es dueño de su data. Si otro servicio necesita esa información, la pide por evento o por API.
Nunca por query directo a la base de datos ajena.
¿Por qué? Porque si compartes la base de datos, cualquier cambio de schema puede romper múltiples servicios al mismo tiempo. Y ahí se fue tu independencia.
Esto se conoce como database per service y suena simple, pero tiene implicaciones importantes, como qué pasa cuando una transacción involucra múltiples servicios (spoiler: necesitas el patrón Saga).
En el tercer artículo de la serie vamos a profundizar en este patrón y en cómo manejar transacciones distribuidas con Sagas.
Patrón 3: Observabilidad desde el día 1
En un monolito, un error aparece en un log. En microservicios, un error puede estar en cualquiera de 10 servicios.
Sin observabilidad, estás debuggeando a ciegas. Y te lo digo por experiencia: no hay nada más frustrante que saber que algo falló y no poder encontrar dónde.
Los tres pilares que necesitas desde el día 1:
1. Logs estructurados con correlation ID
Nota importante: Cada request que entra a tu sistema debe llevar un ID único que viaje por todos los servicios. Cuando algo falla, buscas ese ID y ves el camino completo.
Lambda Powertools te lo da casi gratis, inyecta correlation IDs, estructura tus logs en JSON y agrega contexto automáticamente.
2. Traces distribuidos
AWS X-Ray y AWS Distro for OpenTelemetry (ADOT) te permiten ver el viaje completo de cada request a través de todos los servicios. Puedes identificar exactamente dónde está el bottleneck.
Nota importante: AWS está convergiendo hacia OpenTelemetry como estándar de instrumentación. ADOT te da una distribución optimizada para AWS que envía traces y métricas a X-Ray, CloudWatch y otros destinos.
3. Métricas de negocio
No solo "cuántos errores 500" sino "cuántos pedidos se perdieron por minuto". Las métricas técnicas te dicen que algo falló. Las métricas de negocio te dicen cuánto te costó.
Si no puedes ver qué pasa, no puedes arreglar lo que falla. En el cuarto artículo de la serie vamos a implementar observabilidad completa con Lambda Powertools, X-Ray y métricas custom.
El framework de decisión
Después de todo lo que vimos, quiero dejarte algo práctico. Un framework que puedes usar la próxima vez que alguien diga "necesitamos microservicios":
No empieces por la tecnología. Empieza por las preguntas.
Si la respuesta a todo es no, quédate con tu monolito. Si es sí, extrae con estrategia.
Lo que quiero que te lleves
🧠 Decide con evidencia, no con hype: Microservicios no son el default. Son una herramienta para problemas específicos.
📐 Empieza modular, extrae después: Monolito modular → macro-servicios → microservicios. En ese orden.
🔌 Eventos sobre llamadas directas: Desacopla con EventBridge/SQS. Nunca encadenes Lambdas síncronamente.
🗄️ Cada servicio, su data: Base de datos compartida = monolito disfrazado.
👀 Observabilidad no es opcional: Correlation IDs, X-Ray/OpenTelemetry, métricas de negocio. Desde el día 1.
Qué sigue
Este artículo es el mapa conceptual. Los siguientes artículos de la serie van a profundizar en cada patrón con implementación práctica y código real:
- Comunicación desacoplada con EventBridge y SQS: Implementación paso a paso, trampas comunes y demo funcional
- Database per service y el patrón Saga: Cómo manejar transacciones distribuidas con acciones compensatorias
- Observabilidad en microservicios serverless: Lambda Powertools, X-Ray/OpenTelemetry y métricas de negocio en acción
"Escalar inteligente no es tener más servicios. Es tomar mejores decisiones."
Recursos
Si quieres profundizar más, estos son los recursos oficiales de AWS que recomiendo:
- Implementing Microservices on AWS — Whitepaper completo sobre patrones API-driven, event-driven y data streaming
- Microservices on Serverless Technologies — Arquitecturas serverless con Lambda, API Gateway y Fargate
- Integrating Microservices by Using AWS Serverless Services — Guía prescriptiva sobre comunicación síncrona y asíncrona entre microservicios
- Cloud Design Patterns, Architectures, and Implementations — Patrones como Saga, circuit breaker, event sourcing y strangler fig aplicados con servicios AWS
¿Te resultó útil este artículo? Compártelo con tu equipo. Y si ya pasaste por una migración a microservicios exitosa o no me encantaría escuchar tu experiencia.
Top comments (0)