Los 7 anti‑patrones de microservicios (y cómo evitarlos)

Siete anti‑patrones comunes en arquitecturas de microservicios, por qué son peligrosos y acciones prácticas para evitarlos: límites de servicio, acoplamientos, comunicaciones y observabilidad.
10-03-2026 • 4 min de lectura

Introducción

Los microservicios prometen escalabilidad, despliegue independiente y equipos autónomos. Pero también traen trampas si no se diseñan y operan con disciplina. Aquí tienes siete anti‑patrones comunes, por qué son peligrosos y acciones prácticas para evitarlos.

1) Monolito distribuido (Distributed Monolith)

Qué es: Partes de la misma lógica de negocio quedan dispersas en múltiples servicios pero dependen fuertemente unos de otros en tiempo de ejecución.

Consecuencias:

  • Despliegues acoplados y frágiles.
  • Latencias y fallos en cascada.
  • Pérdida de los beneficios de independencia.

Cómo evitarlo:

  • Definir límites de servicio claros basados en dominio (DDD).
  • Garantizar que cada servicio pueda funcionar en degradación si sus dependencias fallan.
  • Implementar patterns como circuit breakers, colas y eventos asíncronos para romper la sincronía.

Ejemplo (pseudo‑código circuit breaker):

const userService = new CircuitBreaker(() => fetch('/users/123'), { timeout: 2000, retries: 2 });
if (!userService.call()) {
  // degradación: usar cache local o datos por defecto
}

2) Chatty services (APIs excesivamente conversadoras)

Qué es: Diseño que obliga a los clientes a realizar muchas llamadas pequeñas a diferentes servicios para completar una operación simple.

Consecuencias:

  • Latencia alta, peor experiencia de usuario.
  • Mayor probabilidad de fallos intermedios.

Cómo evitarlo:

  • Agregar gateways o BFFs (Backend for Frontend) que agreguen y orquesten llamadas.
  • Diseñar APIs con endpoints que devuelvan lo necesario en menos llamadas (evitar N+1).
  • Evaluar uso de GraphQL o endpoints compuestos donde tenga sentido.

3) Base de datos compartida entre servicios

Qué es: Varios servicios acceden directamente a la misma base de datos o esquema.

Consecuencias:

  • Acoplamiento fuerte a nivel de datos.
  • Dificultad para evolucionar esquemas sin romper otros servicios.
  • Problemas de ownership y seguridad.

Cómo evitarlo:

  • Cada servicio debe ser dueño de su modelo de datos y exponer una API para acceder a él.
  • Si se necesita compartir datos, usar eventos (Event Sourcing / CDC) o replicación controlada.
  • Establecer contratos claros y versionados entre servicios.

4) Sobre‑granularidad (Too fine‑grained services)

Qué es: Dividir en tantos microservicios que terminan siendo dependencias triviales entre sí.

Consecuencias:

  • Complejidad operativa (muchos deployments, muchos endpoints).
  • Latencias y sobrecarga de red.
  • Dificultad para mantener consistencia transaccional.

Cómo evitarlo:

  • Agrupar funcionalidades cohesivas; favorece servicios con responsabilidad completa sobre un subdominio.
  • Aplicar el principio KISS: no dividir por dividir.
  • Revisar la granularidad con métricas (cantidad de llamadas entre servicios, latencia, tamaño de equipo).

5) Falta de automatización y pipelines deficientes

Qué es: Despliegues manuales o pruebas insuficientes para cada servicio.

Consecuencias:

  • Errores humanos y despliegues inconsistentes.
  • Retrocesos caros y time-to-recover largo.

Cómo evitarlo:

  • Implementar CI/CD con tests unitarios, integración y contract tests.
  • Despliegue automatizado con feature flags y despliegues canary/blue‑green.
  • Automatizar infraestructura (IaC) y entornos repetibles.

6) Acoplamiento fuerte a través de llamadas sincrónicas

Qué es: Depender mayoritariamente de llamadas HTTP sincrónicas entre servicios para cada operación.

Consecuencias:

  • Riesgo de cascada de fallos.
  • Latencia acumulada.
  • Difícil de escalar y resiliente.

Cómo evitarlo:

  • Preferir comunicación asíncrona (mensajería, eventos) cuando sea posible.
  • Usar timeouts, retries con backoff exponencial y circuit breakers.
  • Diseñar para consistencia eventual cuando la transaccionalidad global no sea esencial.

7) Ignorar observabilidad y seguridad desde el inicio

Qué es: No instrumentar logs, métricas y trazas, y no pensar en autentificación/autorización y auditoría.

Consecuencias:

  • Detección tardía de incidentes.
  • Incapacidad para depurar problemas distribuidos.
  • Riesgos de seguridad y cumplimiento.

Cómo evitarlo:

  • Implementar trazabilidad distribuida (OpenTelemetry), métricas (Prometheus), y logging centralizado.
  • Definir estándares de telemetría para todos los servicios.
  • Adoptar autenticación central (OAuth2 / OpenID Connect), y políticas de autorización, además de control de secretos y escaneo de imágenes.

Checklist rápido para evitar estos anti‑patrones

  • ¿Cada servicio tiene un dominio claro y dueño? Sí / No
  • ¿Hay un pipeline CI/CD por servicio? Sí / No
  • ¿Se usan timeouts, retries y circuit breakers? Sí / No
  • ¿La comunicación crítica es asíncrona cuando conviene? Sí / No
  • ¿Cada servicio gestiona su propio dato? Sí / No
  • ¿Tenemos trazabilidad, métricas y logging centralizados? Sí / No
  • ¿Existen pruebas de contrato entre servicios? Sí / No

Conclusión breve

Evitar estos anti‑patrones requiere disciplina en diseño, automatización y operación. Prioriza dominios bien definidos, resiliencia (timeouts, circuit breakers, colas), observabilidad y pipelines sólidos. Con esas bases, los microservicios pueden entregar las ventajas prometidas sin convertirse en una fuente constante de complejidad.

Metadatos sugeridos

  • Categoría: Arquitectura de Software
  • Tags: Microservicios, Arquitectura, DevOps