Arquitectura Intermedio

Microservicios

Estilo arquitectónico donde una aplicación se construye como un conjunto de servicios pequeños e independientes, cada uno ejecutando un proceso propio y comunicándose a través de APIs.

Pronunciación

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

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

VentajaPor qué importa
Escalabilidad independienteSi Pagos tiene mucha carga, se escala solo Pagos — no toda la app
Tecnología por servicioUsuarios en Node.js, Reportes en Python, Pagos en Java
Fallos aisladosSi Notificaciones falla, Pedidos sigue funcionando
Equipos independientesCada equipo dueño de su servicio, deploys sin coordinación masiva
Despliegues frecuentesCambiar 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 (> 50 endpoints)
  • 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 (< 5 desarrolladores)
  • El sistema está en etapa temprana o pivotando frecuentemente
  • La complejidad de distribuidos superaría los beneficios

Empresas que usan microservicios

  • Netflix: más de 1000 microservicios para streaming global
  • Amazon: cada función del carrito, checkout, recomendaciones es un servicio
  • Uber: separó su monolito en servicios por tipo de transporte y ciudad

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 protocolo más común para comunicación entre microservicios

Recursos adicionales:

Todos los términos