Desafios de Arquitetura

Use o padrão Strangler Fig:

1. Crie o novo serviço de pedidos
2. Redirecione as leituras primeiro (menor risco)
3. Em seguida, redirecione as escritas
4. Por fim, remova o código de pedidos do monolito

Use Change Data Capture (CDC):

1. Faça um dump inicial dos pedidos históricos para o novo serviço
2. Configure o CDC para replicar as alterações em tempo real do monolito para o novo serviço
3. Quando ambos estiverem sincronizados, redirecione o tráfego

Use o padrão Shadow Traffic:

1. Envie uma cópia de cada request ao novo serviço (sem afetar o usuário)
2. Compare as respostas do monolito e do novo serviço
3. Quando as respostas coincidirem em 99,9%, redirecione o tráfego real

Fase 1 — Preparação (semana 1-2):

• Criar o novo serviço de pedidos com a mesma API
• Configurar o CDC a partir da tabela de pedidos do monolito
• Migrar dados históricos com um script batch

Fase 2 — Verificação (semana 3):

• Ativar o shadow traffic: cada request ao monolito é duplicado para o novo serviço
• Comparar respostas automaticamente e registrar discrepâncias
• Corrigir bugs até que as respostas coincidam

Fase 3 — Migração gradual (semana 4):

• Redirecionar 10% do tráfego de leitura para o novo serviço
• Monitorar latência, erros e consistência dos dados
• Aumentar gradualmente: 25% → 50% → 75% → 100%

Fase 4 — Escritas (semana 5):

• Redirecionar as escritas para o novo serviço
• O novo serviço publica eventos que o monolito consome (para relatórios legados)
• Monitorar intensivamente durante 48 horas

Fase 5 — Limpeza (semana 6):

• Remover o código de pedidos do monolito
• Desativar o CDC
• Atualizar os relatórios para usar a nova fonte de dados

Rollback em qualquer fase: Reverter a configuração do proxy/load balancer para enviar o tráfego ao monolito.

Use uma idempotency key gerada pelo cliente:

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

Antes de processar, verifique se já existe um pagamento com essa key. Se existir, retorne o resultado anterior sem processar novamente.

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
}

Defina uma ordem de prioridade de provedores por tipo de pagamento:

1. Cartão de crédito: Stripe → PayPal
2. Cartão de débito: Stripe → PayPal
3. Transferência: apenas banco

Se o provedor primário falhar com erro recuperável (timeout, 503), tentar o próximo. Se falhar com erro não recuperável (cartão recusado, saldo insuficiente), não repetir a tentativa.

[API de Notificações]
    │
    ▼
[Fila de prioridade]
    ├── Fila CRITICAL (processamento imediato, workers dedicados)
    ├── Fila HIGH (processamento < 1 min)
    ├── Fila NORMAL (processamento < 5 min)
    └── Fila LOW (acumulação para batch)
    │
    ▼
[Notification Processor]
    │
    ├── Verificar preferências do usuário
    ├── Aplicar rate limiting
    ├── Resolver template com variáveis
    │
    ▼
[Channel Router]
    ├──► [Email Provider] (SendGrid/SES)
    ├──► [Push Provider] (Firebase/APNs)
    ├──► [SMS Provider] (Twilio)
    └──► [In-App Store] (WebSocket/DB)

Rate limiting: Usar Redis com um contador por usuário com TTL de 1 hora. Antes de enviar, verificar o contador. Se exceder o limite, enfileirar para o próximo período.

Deduplicação: Usar uma chave composta (userId + notificationType + entityId) com TTL para evitar duplicatas.

Métricas (por serviço):

• Latência: p50, p90, p95, p99 por endpoint
• Taxa de erros: 4xx e 5xx por endpoint
• Throughput: requests por segundo
• Saturação: CPU, memória, conexões de DB, pool de threads

Distributed tracing:

• Gerar um traceId no API Gateway
• Propagar via header X-Trace-Id para todos os serviços
• Cada serviço registra spans com início, fim e metadata
• Usar OpenTelemetry como padrão

Alertas:

• Latência p99 > 2x do baseline por mais de 5 minutos
• Taxa de erros 5xx > 1% por mais de 2 minutos
• Fila de mensagens crescendo por mais de 10 minutos
• CPU > 80% por mais de 5 minutos

Dashboard de plantão:

• Visão geral: health de todos os serviços (verde/amarelo/vermelho)
• Visão de fluxo: latência por etapa do checkout
• Visão de traces: os 10 traces mais lentos da última hora
• Visão de erros: erros agrupados por tipo e serviço