Articles

Une dépendance ne répond plus : servir une copie, attendre ou refuser dépend de l’opération. Les réponses HTTP doivent rendre ce choix clair pour le client.

Une commande expédiée met à jour une liste et déclenche un courriel. Ces effets ne se réparent pas de la même façon : voici comment organiser leur reprise.

Dans un monolithe, un traitement différé peut laisser deux modules en décalage. Quand faut-il attendre une réponse et comment gérer une mise à jour tardive ?

Une commande validée peut manquer quelques instants dans une liste, même dans un monolithe. Voici d’où vient ce délai et comment le rendre compréhensible.

Un service ralentit ou un message revient en double : timeout, retry, outbox et idempotence répondent à des risques différents. Voici comment les combiner.

Au retour du réseau, les données peuvent diverger et certains paiements être déjà faits. Comment remettre les copies à jour et traiter les effets à corriger.

Une donnée absente ou ancienne ne bloque pas tous les usages. Choisir, opération par opération, quand attendre, limiter le service ou accepter un retard.

CAP aide à choisir quelles opérations peuvent continuer pendant une coupure réseau. Il ne suffit pas à décrire les performances ou la fiabilité d’un système.

Deux caisses partagent un stock, puis perdent leur connexion. Cet exemple explique les trois notions de CAP et les choix possibles pendant une coupure réseau.