Patrones de Arquitectura

La elección del patrón de arquitectura es una de las decisiones con mayor impacto a largo plazo. No existe un patrón universal — cada uno resuelve problemas específicos y trae sus propios costos. Esta guía te ayuda a tomar esa decisión con criterio.

Patrones vs Categorías de servicios

Los patrones de arquitectura (esta página) responden “¿qué estilo arquitectónico aplico?” — son enfoques generales (Microservicios, BFF, Event-Driven, CQRS).

Las categorías de servicios (Clasificación de Servicios) responden “¿qué tipo de servicio construyo?” — son las 13 categorías oficiales agrupadas en 4 capas estratégicas (Experience, Domain, Integration, Platform).

Los dos conceptos son complementarios: eliges un patrón (ej. Microservicios) y luego para cada microservicio eliges su categoría (backend, bff, data, etc.).

Patrones de Arquitectura — Cuándo Usar Cada Uno

Microservicios

API GatewayService AService BMessage Bus

Usar cuando Dominios independientes, equipos autónomos, escalado diferenciado

Evitar si MVP o equipos < 3 personas

Complejidad

BFF (Backend for Frontend)

BFF WebBFF MobileCore Services

Usar cuando Múltiples clientes (web, mobile, terceros) con necesidades distintas

Evitar si Un solo canal de consumo

Complejidad

Event-Driven

PublisherPub/SubSubscriber ASubscriber B

Usar cuando Procesos asíncronos, integración entre dominios, alta tolerancia a fallos

Evitar si Operaciones que requieren respuesta síncrona inmediata

Complejidad

Monolito Modular

Módulo AMódulo BMódulo CDB compartida

Usar cuando Producto nuevo, equipo pequeño, necesidad de velocidad de entrega

Evitar si Cuando hay necesidad real de escalar partes independientemente

Complejidad

API Gateway

GatewayAuthRate LimitRouting

Usar cuando Punto de entrada único, rate limiting, autenticación centralizada

Evitar si Comunicación interna entre servicios (usar service mesh)

Complejidad

CQRS

CommandEvent StoreRead ModelQuery

Usar cuando Lecturas y escrituras con patrones muy diferentes, reporting pesado

Evitar si CRUDs simples sin diferencia de carga lectura/escritura

Complejidad

Mensaje clave La elección de patrón se valida en la revisión de arquitectura con el equipo de plataforma. No existe un patrón universal — la decisión depende del contexto del producto, equipo y dominio de negocio.

Anatomía de Patrones — Flujo Arquitectónico

Cómo se conectan los componentes en cada patrón adoptado en HERA

Microservicios

API Gateway (Ingress)

↓↓

Service A (Node.js) Service B (Java)

↓↓

Cloud SQL (Postgres) Cloud SQL (Postgres)

BFF (Backend for Frontend)

Web App Mobile App

↓↓

BFF Web (Node.js) BFF Mobile (Node.js)

↓↓

Backend APIs

↓

Cloud SQL (Postgres)

Event-Driven

Producer (backend)

↓

Pub/Sub (Topic)

↓↓

Consumer A (worker) Consumer B (worker)

Monolito Modular

Monolito Modular

Auth Module Orders Module Inventory Module Notifications Module

↓

PostgreSQL DB (Shared)

API Gateway

Clients

↓

API Gateway (Apigee / Ingress)

↓↓↓

Service A Service B Service C

Mensaje clave Cada patrón resuelve un problema específico. Consulta la Matriz de Decisión al final de esta página para elegir el correcto.

---

Microservicios

Cuándo es el patrón correcto

• Dominios claramente separados con equipos autónomos (ej: ecommerce tiene catálogo, carrito, pagos, envíos como servicios independientes)
• Escalado diferenciado — un servicio recibe 100x más tráfico que otro
• Equipos de 5+ personas que necesitan desplegar independientemente
• Tecnologías mixtas — un servicio en Node.js, otro en Java, otro en Python

Anatomía en HERA

Cada servicio:

• Tiene su propio repositorio en GitLab siguiendo la estructura de repos
• Tiene su propio pipeline CI/CD
• Se despliega como un Pod independiente en GKE
• Tiene su propia base de datos (no comparte schemas)
• Se comunica vía HTTP/gRPC (síncrono) o Pub/Sub (asíncrono)

Anti-Patterns

Anti-patrón: Monolito Distribuido

Si todos tus microservicios se tienen que desplegar juntos para que funcionen, no tienes microservicios — tienes un monolito distribuido con la complejidad de microservicios y ninguno de sus beneficios. Cada servicio debe poder desplegarse y escalar independientemente.

• Base de datos compartida entre servicios → rompe la autonomía
• Llamadas síncronas en cascada → crea acoplamientos frágiles
• Orquestación centralizada → prefiere coreografía vía eventos
• Demasiados servicios para un equipo pequeño → overhead operacional insostenible

---

BFF (Backend for Frontend)

Cuándo es el patrón correcto

• Múltiples clientes con necesidades diferentes: app web (datos ricos), app móvil (datos ligeros), API para terceros (estructura estable)
• Equipos frontend que necesitan evolucionar la API de su cliente sin afectar a otros

Anatomía en HERA

Cada BFF:

• Pertenece al equipo frontend que lo consume
• Agrega, filtra y transforma datos de los servicios core
• Puede tener lógica de caché y formateo específica del canal
• Se despliega con el Golden Pipeline de HERA

Regla Práctica

Un BFF debe ser ligero — si tiene lógica de negocio pesada, probablemente debería ser un servicio core. El BFF solo orquesta y adapta.

---

Event-Driven

Cuándo es el patrón correcto

• Operaciones asíncronas que no necesitan respuesta inmediata (envío de emails, procesamiento de pedidos, sincronización de inventarios)
• Integración entre dominios donde no quieres acoplamiento directo
• Alta tolerancia a fallos — si un consumer falla, los mensajes se retienen

Anatomía en HERA

HERA utiliza Google Cloud Pub/Sub como backbone de mensajería.

Estándares de eventos en HERA

{
  "eventId": "uuid-v4",
  "eventType": "order.created",
  "source": "ecommerce.orders",
  "timestamp": "2026-04-02T10:30:00Z",
  "version": "1.0",
  "data": {
    "orderId": "ORD-12345",
    "customerId": "USR-67890",
    "total": 1500.00
  }
}

Campo	Obligatorio	Descripción
eventId	Sí	UUID único del evento
eventType	Sí	{dominio}.{entidad}.{acción} en dot-notation
source	Sí	Servicio que emite el evento
timestamp	Sí	ISO 8601 con timezone
version	Sí	Versión del schema del evento
data	Sí	Payload específico del evento

Idempotencia

Los consumers deben ser idempotentes — pueden recibir el mismo evento más de una vez. Usa el eventId para deduplicar si es necesario.

---

Monolito Modular

Cuándo es el patrón correcto

• Producto nuevo o MVP que necesita velocidad de entrega
• Equipo pequeño (2-5 personas) donde la coordinación inter-servicio es overhead puro
• Dominio de negocio simple que no justifica la complejidad de microservicios

Anatomía en HERA

Reglas para que un monolito no se convierta en un monolito desordenado:

1. Módulos con boundaries claros — cada módulo expone una API interna, no accede directamente a las tablas de otro módulo
2. Un módulo = un dominio de negocio (usuarios, pedidos, reportes)
3. Tests por módulo — cada módulo tiene sus propios tests unitarios y de integración
4. Preparado para extraer — si un módulo crece, puede convertirse en microservicio sin reescribir

Migración Gradual

Muchos productos exitosos empezaron como monolitos modulares y extrajeron servicios solo cuando hubo una necesidad real de escalado independiente. No empieces con microservicios por anticipación.

---

API Gateway

En HERA, el API Gateway es el punto de entrada único para todo tráfico externo hacia los servicios. Se implementa con Google Cloud Load Balancer + Cloud Armor + Ingress Controller en GKE.

Responsabilidades del Gateway

Función	Implementación
TLS termination	Cloud Load Balancer
Rate limiting	Cloud Armor policies
Autenticación	JWT validation / OAuth 2.0
Routing	Ingress Controller (path-based)
DDoS protection	Cloud Armor
CORS	Configuración en Ingress

Anti-Pattern

No pongas lógica de negocio en el Gateway. Su responsabilidad es cross-cutting concerns (auth, rate limit, routing), no transformación de datos ni orquestación.

---

CQRS (Command Query Responsibility Segregation)

Cuándo es el patrón correcto

• Lecturas y escrituras tienen patrones radicalmente diferentes (muchas lecturas vs. pocas escrituras complejas)
• Reporting pesado que requiere modelos desnormalizados
• Audit trail completo donde necesitas reconstruir el estado en cualquier punto del tiempo

Complejidad

CQRS es uno de los patrones más complejos. Introduce consistencia eventual entre el modelo de escritura y lectura. Solo úsalo cuando la diferencia entre patrones de lectura/escritura lo justifique claramente. Para CRUDs estándar, es overkill.

---

Matriz de Decisión

Usa esta tabla para guiar tu elección:

Criterio	Monolito Modular	Microservicios	BFF	Event-Driven	CQRS
Equipo < 5 personas	✅	❌	➖	➖	❌
Múltiples equipos autónomos	❌	✅	➖	✅	➖
Múltiples canales (web+mobile)	➖	➖	✅	➖	➖
Operaciones asíncronas	➖	➖	➖	✅	➖
Escalado diferenciado	❌	✅	➖	✅	➖
Reporting pesado	➖	➖	➖	➖	✅
Velocidad de entrega inicial	✅	❌	➖	❌	❌
Costo operacional bajo	✅	❌	➖	➖	❌

Leyenda: ✅ Recomendado · ❌ No recomendado · ➖ Depende del contexto

Los patrones se combinan

En la práctica, una aplicación madura usa varios patrones. Un producto de ecommerce puede tener microservicios para su core, un BFF para web y mobile, eventos entre dominios (pedidos → inventario) y CQRS para reporting. La clave es aplicar cada patrón donde aporta valor.