CQRS (Command Query Responsibility Segregation) en production : cohérence, erreurs et stratégies de récupération (CQRS Command Query Responsibility Segregation EN Production Coherence Erreurs Et Strategies DE Recuperation)

How these failures look to a user

If a banking balance is delayed by two seconds, a user may think money disappeared. If a like count is delayed by two seconds, most users may accept it. The same technical lag creates two different product risks.

Likewise, if the same OrderPlaced message arrives twice, inventory can be reduced twice. Production concepts should therefore be read not only as definitions, but through their effect on the user and the business.

La vraie question en Production

Le chemin heureux est simple : commande acceptée, événement libéré, projection mise à jour. En Production, le message arrive deux fois, le consommateur prend du retard, la projection est interrompue ou l'utilisateur ne peut pas voir l'ordre qu'il a écrit dans la liste.```text Command accepted → event published → projection delayed → user refreshes "Siparişim kayboldu mu?"

## Concepts à la première mention```text
📦 Consistency lag
Write başarılı olduktan sonra read modelin güncellenmesine kadar geçen süre.

📦 Retry
Geçici teknik hatada aynı işi kontrollü biçimde yeniden deneme.

📦 Dead-letter queue (DLQ)
Normal akışta işlenemeyen mesajların incelenmek üzere ayrıldığı kuyruk.

📦 Checkpoint
Projection'ın güvenle işlediği son event konumu.
```**La cohérence éventuelle** ne signifie pas que les données sont fausses ; différents modèles arrivent à la même vérité à des moments différents. Si cela est acceptable, le produit doit l'expliquer correctement à l'utilisateur ; sinon, il doit choisir une stratégie de cohérence différente pour la requête critique.

## Every defence has a reason

- We keep a **checkpoint** **because** a replay needs to know where a projection can safely resume.
- We need **idempotency** **because** applying a duplicate event twice corrupts real business effects such as inventory or payment.
- We limit **retry** **because** repeating a malformed message cannot repair it; it can only amplify load and incorrect impact.
- We use a **DLQ** **because** a message unresolved by the normal flow needs visible ownership and investigation.
- The **partition key is the aggregate ID** **because** the causal order of one aggregate matters more than global event order.
- We **replay** **because** verified event history remains correct even when a projection is broken.

## Le délai de cohérence est une décision produit, pas technique

Si un paiement n'apparaît pas dans la liste des commandes pendant deux secondes après sa réception, cela peut ressembler à une perte de données pour l'utilisateur. Déterminez d’abord le contrat visible : quel écran doit être mis à jour et combien de temps après la transaction ?```text
POST /orders → 202 Accepted + orderId + version
GET /orders/{id}?minVersion=42
  → projection 42'ye ulaştıysa güncel görünüm
  → henüz ulaşmadıysa "işleniyor" durumu
```Une interface utilisateur optimiste, un sondage ou une attente de version peuvent être utilisés. Ceux-ci ne réinitialisent pas le décalage ; **parce** que le vrai travail consiste à montrer honnêtement à l'utilisateur la signification du retard. Pour les décisions critiques, le résultat du commandement reste vrai.

## Événement en double et corruption de séquence

La livraison au moins une fois normalise la répétition du même message. Traiter le même événement de commande une deuxième fois peut réduire le nombre d'inventaires de deux fois. Le consommateur doit vérifier l'ID d'événement et la version globale.```text
if event.id already processed: ignore
if event.version <= projection.version: ignore
apply event
store checkpoint and event id
```Ce contrôle entraîne un coût moyen O(1) ou O(log n) avec recherche indexée. Si le classement est garanti uniquement au sein d'une partition, la clé de partition doit être l'ID d'agrégat ; **parce** que l'ordre causal du même ordre est important par rapport à l'ordre global.

## Nouvelle tentative, DLQ et moment de décision de l'opérateur

Toutes les erreurs ne doivent pas être réessayées. Le délai d'attente du réseau peut être temporaire ; Un schéma d'événement invalide est une erreur permanente.

| Type d'erreur | Réaction | Pourquoi |
| --- | --- | --- |
| Délai d'attente / 503 | Réessayez avec une interruption exponentielle | La dépendance peut être guérie |
| Limite de taux | Nouvelle tentative retardée | Se rétablir sans alourdir le fardeau |
| Erreur de validation de schéma | DLQ + alarme | Réessayer, impossible de corriger le message |
| Violation des règles métier | Enregistrer, réviser, compenser | Une nouvelle tentative automatique peut amplifier les faux impacts |

DLQ n'est pas un dump. Chaque message doit avoir un propriétaire, une heure de révision, une procédure de relecture et une alarme.

## Comment récupérer si la projection est corrompue ?

La projection n’est pas un cache, c’est une vue métier reproductible.```text
1. Consumer'ı durdur veya yeni projection sürümü oluştur
2. Son güvenli checkpoint'i doğrula
3. Event stream'i kontrollü replay et
4. Sayım ve örnek veri doğrulaması yap
5. Trafiği yeni projection'a yönlendir
6. Lag ve hata oranını izle
```Le coût de relecture est O(n), linéaire avec le nombre d'événements. Un instantané ou une relecture segmentée peut réduire ce phénomène ; Mais la source de l’instantané n’est pas réelle. **Parce que** l'enregistrement sur lequel s'appuyer pour la récupération est l'historique des événements vérifié.

## Le chemin de l'échec de Saga

En cas d’échec de paiement dans le e-commerce, le stock ne doit pas rester éternellement réservé. Saga n’est pas un retour en arrière technique, mais une compensation qui a du sens sur le plan commercial.```text
Reserve inventory → Capture payment → Create shipment
                 payment fails → Release inventory
```La compensation doit également être idempotente : l'inventaire ne doit pas augmenter deux fois si ReleaseInventory s'exécute deux fois. La chorégraphie est légère sur les petits flux locaux ; L'orchestration fournit une machine à états et un point de surveillance unique dans un processus en plusieurs étapes.

## Observabilité

Mesurez le décalage du consommateur, le nombre de tentatives, la profondeur DLQ, l’ancienneté du point de contrôle, le taux de duplication et le temps de traitement de bout en bout. Déplacez l'ID de trace de la commande vers l'événement, vers le consommateur et vers la requête renvoyée à l'utilisateur. L’alarme prend du sens en termes d’impact sur l’utilisateur, et non en termes de mesures techniques.

## Correspondances qui créent une fausse confiance```text
❌ Retry = güvenilirlik
✓ Retry, yalnızca geçici hatada ve idempotent işlemde güvenlidir.

❌ DLQ = kurtarma
✓ DLQ, inceleme ve replay sürecinin başlangıcıdır.

❌ Replay = her zaman güvenli
✓ Sürümleme ve yan etkiler ayrılmadan replay etkiyi tekrar üretebilir.

❌ Eventual consistency = rastgele gecikme
✓ Gecikme ölçülmeli, ürünle kabul edilmeli ve kullanıcıya açıklanmalıdır.

Contrôle de l'état de préparation de la production

1. Avez-vous un objectif de décalage de cohérence visible pour l'utilisateur ?
2. Est-il sans danger pour les événements en double et hors service des consommateurs ?
3. La politique de nouvelle tentative fait-elle la distinction entre les erreurs temporaires et permanentes ?
4. Le propriétaire du message DLQ et du runbook de réexécution est-il défini ?
5. Pouvez-vous reconstruire en toute sécurité Projection sur des données de production ?
6. Les compensations de Saga sont-elles idempotentes ?

Si vous ne pouvez pas répondre à chacune de ces questions avec des preuves, le système peut sembler inévolutif ; mais il n'est pas encore opérationnel.

Que faut-il retenir de cet article ?

1. La cohérence éventuelle est un contrat qui doit être géré par l'expérience utilisateur.
2. Les doublons et la corruption des commandes sont normaux dans le cadre d'une livraison distribuée, et non dans les cas extrêmes.
3. Retry est un système de récupération conçu avec DLQ et replay.
4. Si la Projection n’est pas reconstructible, elle se transforme en dette opérationnelle.
5. Saga ne revient pas en arrière ; compense l’impact commercial.

L'architecture de production ne consiste pas à ce que les messages arrivent correctement du premier coup ; Cela se voit dans la façon dont vous agissez lorsqu’ils arrivent deux fois, en retard ou dans des virages inattendus.