Défis d'Architecture

Utilise le pattern Strangler Fig :

1. Crée le nouveau service de commandes
2. Redirige d’abord les lectures (moins de risque)
3. Redirige ensuite les écritures
4. Enfin, supprime le code des commandes du monolithe

Utilise le Change Data Capture (CDC) :

1. Fais un dump initial des commandes historiques vers le nouveau service
2. Configure le CDC pour répliquer les changements en temps réel du monolithe vers le nouveau service
3. Lorsque les deux sont synchronisés, redirige le trafic

Utilise le pattern Shadow Traffic :

1. Envoie une copie de chaque requête au nouveau service (sans impacter l’utilisateur)
2. Compare les réponses du monolithe et du nouveau service
3. Lorsque les réponses coïncident à 99,9 %, redirige le trafic réel

Phase 1 — Préparation (semaine 1-2) :

• Créer le nouveau service de commandes avec la même API
• Configurer le CDC depuis la table des commandes du monolithe
• Migrer les données historiques avec un script batch

Phase 2 — Vérification (semaine 3) :

• Activer le shadow traffic : chaque requête vers le monolithe est dupliquée vers le nouveau service
• Comparer automatiquement les réponses et enregistrer les divergences
• Corriger les bugs jusqu’à ce que les réponses coïncident

Phase 3 — Migration progressive (semaine 4) :

• Rediriger 10 % du trafic de lecture vers le nouveau service
• Surveiller la latence, les erreurs et la cohérence des données
• Augmenter progressivement : 25 % → 50 % → 75 % → 100 %

Phase 4 — Écritures (semaine 5) :

• Rediriger les écritures vers le nouveau service
• Le nouveau service publie des événements que le monolithe consomme (pour les rapports legacy)
• Surveiller intensivement pendant 48 heures

Phase 5 — Nettoyage (semaine 6) :

• Supprimer le code des commandes du monolithe
• Désactiver le CDC
• Mettre à jour les rapports pour utiliser la nouvelle source de données

Rollback à n’importe quelle phase : Rétablir la configuration du proxy/load balancer pour envoyer le trafic vers le monolithe.

Utilise une idempotency key générée par le client :

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

Avant de traiter, vérifie s’il existe déjà un paiement avec cette clé. S’il existe, retourne le résultat précédent sans le traiter à nouveau.

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
}

Définis un ordre de priorité des fournisseurs par type de paiement :

1. Carte de crédit : Stripe → PayPal
2. Carte de débit : Stripe → PayPal
3. Virement : uniquement banque

Si le fournisseur principal échoue avec une erreur récupérable (timeout, 503), essayer avec le suivant. S’il échoue avec une erreur non récupérable (carte refusée, fonds insuffisants), ne pas réessayer.

[API de Notifications]
    │
    ▼
[File de priorité]
    ├── File CRITICAL (traitement immédiat, workers dédiés)
    ├── File HIGH (traitement < 1 min)
    ├── File NORMAL (traitement < 5 min)
    └── File LOW (accumulation pour batch)
    │
    ▼
[Notification Processor]
    │
    ├── Vérifier les préférences de l'utilisateur
    ├── Appliquer le rate limiting
    ├── Résoudre le template avec les variables
    │
    ▼
[Channel Router]
    ├──► [Email Provider] (SendGrid/SES)
    ├──► [Push Provider] (Firebase/APNs)
    ├──► [SMS Provider] (Twilio)
    └──► [In-App Store] (WebSocket/DB)

Rate limiting : Utiliser Redis avec un compteur par utilisateur avec un TTL de 1 heure. Avant d’envoyer, vérifier le compteur. Si la limite est dépassée, mettre en file d’attente pour la période suivante.

Déduplication : Utiliser une clé composée (userId + notificationType + entityId) avec un TTL pour éviter les doublons.

Métriques (par service) :

• Latence : p50, p90, p95, p99 par endpoint
• Taux d’erreurs : 4xx et 5xx par endpoint
• Throughput : requêtes par seconde
• Saturation : CPU, mémoire, connexions de DB, pool de threads

Distributed tracing :

• Générer un traceId dans l’API Gateway
• Le propager via le header X-Trace-Id à tous les services
• Chaque service enregistre des spans avec début, fin et metadata
• Utiliser OpenTelemetry comme standard

Alertes :

• Latence p99 > 2x du baseline pendant plus de 5 minutes
• Taux d’erreurs 5xx > 1 % pendant plus de 2 minutes
• File de messages qui grandit pendant plus de 10 minutes
• CPU > 80 % pendant plus de 5 minutes

Dashboard de garde :

• Vue générale : health de tous les services (vert/jaune/rouge)
• Vue de flux : latence par étape du checkout
• Vue des traces : les 10 traces les plus lents de la dernière heure
• Vue des erreurs : erreurs regroupées par type et par service