Retos de Arquitectura

Usa el patrón Strangler Fig:

1. Crea el nuevo servicio de órdenes
2. Redirige las lecturas primero (menos riesgo)
3. Luego redirige las escrituras
4. Finalmente, elimina el código de órdenes del monolito

Usa Change Data Capture (CDC):

1. Haz un dump inicial de las órdenes históricas al nuevo servicio
2. Configura CDC para replicar cambios en tiempo real del monolito al nuevo servicio
3. Cuando ambos están sincronizados, redirige el tráfico

Usa el patrón Shadow Traffic:

1. Envía una copia de cada request al nuevo servicio (sin afectar al usuario)
2. Compara las respuestas del monolito y del nuevo servicio
3. Cuando las respuestas coinciden en un 99.9%, redirige el tráfico real

Fase 1 — Preparación (semana 1-2):

• Crear el nuevo servicio de órdenes con la misma API
• Configurar CDC desde la tabla de órdenes del monolito
• Migrar datos históricos con un script batch

Fase 2 — Verificación (semana 3):

• Activar shadow traffic: cada request al monolito se duplica al nuevo servicio
• Comparar respuestas automáticamente y registrar discrepancias
• Corregir bugs hasta que las respuestas coincidan

Fase 3 — Migración gradual (semana 4):

• Redirigir 10% del tráfico de lectura al nuevo servicio
• Monitorear latencia, errores y consistencia de datos
• Incrementar gradualmente: 25% → 50% → 75% → 100%

Fase 4 — Escrituras (semana 5):

• Redirigir escrituras al nuevo servicio
• El nuevo servicio publica eventos que el monolito consume (para reportes legacy)
• Monitorear intensivamente durante 48 horas

Fase 5 — Limpieza (semana 6):

• Eliminar el código de órdenes del monolito
• Desactivar CDC
• Actualizar reportes para usar la nueva fuente de datos

Rollback en cualquier fase: Revertir la configuración del proxy/load balancer para enviar tráfico al monolito.

Usa una idempotency key generada por el cliente:

POST /payments
Headers: Idempotency-Key: uuid-unique-per-payment
Body: { orderId, amount, currency, provider }

Antes de procesar, verifica si ya existe un pago con esa key. Si existe, retorna el resultado anterior sin procesar de nuevo.

Payment {
  id: UUID
  idempotencyKey: string (unique)
  orderId: string
  amount: decimal
  currency: string
  status: PENDING | PROCESSING | COMPLETED | FAILED | REFUNDED
  provider: STRIPE | PAYPAL | BANK_TRANSFER
  providerTransactionId: string?
  attempts: PaymentAttempt[]
  createdAt: timestamp
  updatedAt: timestamp
}

PaymentAttempt {
  id: UUID
  paymentId: UUID
  provider: string
  status: SUCCESS | FAILED | TIMEOUT
  errorCode: string?
  errorMessage: string?
  responseTime: number
  attemptedAt: timestamp
}

Define un orden de prioridad de proveedores por tipo de pago:

1. Tarjeta de crédito: Stripe → PayPal
2. Tarjeta de débito: Stripe → PayPal
3. Transferencia: solo banco

Si el proveedor primario falla con error recuperable (timeout, 503), intentar con el siguiente. Si falla con error no recuperable (tarjeta rechazada, fondos insuficientes), no reintentar.

[API de Notificaciones]
    │
    ▼
[Cola de prioridad]
    ├── Cola CRITICAL (procesamiento inmediato, workers dedicados)
    ├── Cola HIGH (procesamiento < 1 min)
    ├── Cola NORMAL (procesamiento < 5 min)
    └── Cola LOW (acumulación para batch)
    │
    ▼
[Notification Processor]
    │
    ├── Verificar preferencias del usuario
    ├── Aplicar rate limiting
    ├── Resolver template con variables
    │
    ▼
[Channel Router]
    ├──► [Email Provider] (SendGrid/SES)
    ├──► [Push Provider] (Firebase/APNs)
    ├──► [SMS Provider] (Twilio)
    └──► [In-App Store] (WebSocket/DB)

Rate limiting: Usar Redis con un contador por usuario con TTL de 1 hora. Antes de enviar, verificar el contador. Si excede el límite, encolar para el siguiente período.

Deduplicación: Usar una clave compuesta (userId + notificationType + entityId) con TTL para evitar duplicados.

Métricas (por servicio):

• Latencia: p50, p90, p95, p99 por endpoint
• Tasa de errores: 4xx y 5xx por endpoint
• Throughput: requests por segundo
• Saturación: CPU, memoria, conexiones de DB, pool de threads

Distributed tracing:

• Generar un traceId en el API Gateway
• Propagar via header X-Trace-Id a todos los servicios
• Cada servicio registra spans con inicio, fin y metadata
• Usar OpenTelemetry como estándar

Alertas:

• Latencia p99 > 2x del baseline por más de 5 minutos
• Tasa de errores 5xx > 1% por más de 2 minutos
• Cola de mensajes creciendo por más de 10 minutos
• CPU > 80% por más de 5 minutos

Dashboard de guardia:

• Vista general: health de todos los servicios (verde/amarillo/rojo)
• Vista de flujo: latencia por paso del checkout
• Vista de traces: los 10 traces más lentos de la última hora
• Vista de errores: errores agrupados por tipo y servicio