ArquitecturaIntermedio

Microservicios

Estilo de arquitectura donde una aplicación se construye como un conjunto de servicios pequeños e independientes que se comunican mediante APIs.

Pronunciación

/ˌmaɪ.krəʊˈsɜː.vɪs.ɪz/
"mai-kro-sér-vi-sis"
Escuchar en:Forvo

Qué es

Los microservicios son un estilo de arquitectura de software donde una aplicación se divide en servicios pequeños, independientes y especializados. Cada servicio:

  • Hace una sola cosa bien (principio de responsabilidad única)
  • Tiene su propia base de datos o almacenamiento
  • Se comunica con otros servicios via APIs
  • Se puede desplegar, escalar y actualizar de forma independiente

Monolito vs Microservicios

Arquitectura Monolítica (tradicional)

┌─────────────────────────────────────────┐
│              APP MONOLÍTICA             │
│  ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│  │ Usuarios │ │ Pedidos  │ │ Pagos   │ │
│  └──────────┘ └──────────┘ └─────────┘ │
│  ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│  │Inventario│ │Reportes  │ │Notif.   │ │
│  └──────────┘ └──────────┘ └─────────┘ │
│          ↓ Una sola base de datos ↓     │
└─────────────────────────────────────────┘

Problema: si necesitas actualizar el módulo de Pagos, debes redesplegar toda la aplicación.

Arquitectura de Microservicios

[Servicio Usuarios] ←→ [Servicio Pedidos] ←→ [Servicio Pagos]
       ↓                      ↓                     ↓
  [DB Usuarios]          [DB Pedidos]          [DB Pagos]

Cada servicio se actualiza, escala y despliega por separado.

Ventajas

Ventaja Por qué importa
Escalabilidad independiente Si Pagos tiene mucha carga, se escala solo Pagos — no toda la app
Tecnología por servicio Usuarios en Node.js, Reportes en Python, Pagos en Java
Fallos aislados Si Notificaciones falla, Pedidos sigue funcionando
Equipos independientes Cada equipo dueño de su servicio, deploys sin coordinación masiva
Despliegues frecuentes Cambiar un servicio no afecta a los demás

Desafíos

Los microservicios no son gratuitos. Introducen complejidad:

  • Comunicación entre servicios: ¿Cómo hablan entre sí? ¿Qué pasa si uno falla?
  • Datos distribuidos: mantener consistencia entre múltiples bases de datos es difícil
  • Observabilidad: trazar un error que pasó por 5 servicios requiere herramientas específicas
  • Overhead operacional: cada servicio necesita su propio CI/CD, monitoring, logs

Por eso los microservicios son más adecuados para sistemas complejos con equipos grandes.

Cuándo tiene sentido

✅ Microservicios funcionan bien cuando:

  • El sistema es grande y complejo, con dominios de negocio bien diferenciados
  • Varios equipos trabajan en paralelo sobre distintas partes
  • Partes del sistema tienen requerimientos de escala muy diferentes
  • Necesitas alta disponibilidad (fallos parciales son aceptables)

❌ Un monolito bien estructurado es mejor cuando:

  • El equipo es pequeño
  • El sistema está en etapa temprana o pivotando frecuentemente
  • La complejidad de distribuidos superaría los beneficios

Empresas que usan microservicios

  • Netflix: migró de un monolito a una arquitectura de microservicios en la nube, un caso citado como referencia temprana del patrón
  • Amazon: adoptó temprano una arquitectura orientada a servicios, con equipos dueños de servicios como carrito, checkout o recomendaciones
  • Uber: pasó de un monolito a unos 2,200 microservicios críticos y en 2020 los reorganizó por dominios (DOMA) para reducir su complejidad

Términos relacionados

  • API - El canal de comunicación entre microservicios
  • Docker - Cada microservicio corre típicamente en su propio contenedor
  • DevOps - Las prácticas necesarias para operar microservicios exitosamente
  • REST - El estilo más común para comunicación entre microservicios

Recursos adicionales:

Artículos relacionados

Todos los términos