Cache HTTP, cache applicatif et Messenger

Comprendre le mécanisme

Le cache HTTP s’appuie sur les en-têtes de réponse : expiration pour la fraîcheur, validateurs comme ETag pour la revalidation. Une réponse personnelle ne doit pas devenir publique par erreur. Un cache applicatif mémorise un calcul selon une clé et une stratégie d’invalidation ; une clé omettant un tenant ou une locale peut mélanger les résultats. Une durée arbitraire n’est pas une preuve de cohérence.

Raisonner et vérifier

Messenger sépare émission et traitement de messages ; un transport asynchrone implique des workers et une politique d’échec. Une livraison peut être répétée, notamment après un incident. Rendez le handler idempotent avec une clé métier stable, et observez les erreurs définitives. Ne confondez pas l’acceptation d’un message avec la réussite de tous ses effets.

Clé et portée

Un cache doit définir ses clés et sa portée. La personnalisation doit entrer dans le contrat de sélection. Un tableau de bord personnel ne doit pas être stocké comme une réponse publique partagée. Une clé de calcul dépendant du tenant doit inclure ce tenant, ainsi que les autres dimensions réellement variables.

Invalidation cohérente

Une invalidation doit accompagner les changements pertinents. La propagation doit être conçue. Après modification d’un prix, invalidez les entrées qui en dépendent ou utilisez une version de clé. Un TTL borne parfois l’obsolescence mais ne fournit pas une mise à jour immédiate garantie.

Synchrone ou asynchrone

Messenger peut traiter un message de manière asynchrone. La fin dépend du transport et du handler. Le routage Messenger détermine si un message est envoyé vers un transport ou traité dans le processus. Vérifiez la configuration effective ; le seul appel dispatch ne garantit pas un traitement différé.

Livraison répétée

Une livraison répétée demande de l’idempotence. Les reprises peuvent répéter le traitement. Après effet durable et perte d’acquittement, le message peut revenir. Utilisez un identifiant métier unique et une déduplication durable dans la même transaction que l’effet local, puis testez deux livraisons successives.

Frontière transactionnelle

Un handler doit gérer ses limites transactionnelles. Les systèmes ont des frontières de transaction distinctes. Une transaction SQL ne peut pas annuler un paiement déjà accepté par un prestataire. Modélisez les états et la reprise ; un outbox transactionnel traite le lien entre écriture locale et émission différée.

Reprises bornées

Une stratégie de retry doit être bornée. Il peut amplifier une panne et bloquer la file. Distinguez erreur transitoire et message invalide. Configurez délai, plafond et jitter appropriés ; une reprise illimitée d’une opération non idempotente peut multiplier les effets au lieu de restaurer le service.

File d’échec

Une file d’échec demande une procédure d’exploitation. Le classement ne remplace pas l’investigation et la reprise. Documentez qui examine un message en échec, quelles données sont sensibles et comment le rejouer. La correction doit préserver l’identité métier pour éviter de transformer une intervention d’exploitation en nouvelle opération.

Workers et release

Les workers doivent suivre le cycle de release. Un processus peut conserver son code et état jusqu’à redémarrage. Un processus long peut conserver ancien code ou références d’objets. Organisez son arrêt contrôlé et son redémarrage autour de la release, en respectant les messages en cours et leur possibilité de relivraison.

Payload minimal

Les payloads doivent éviter les secrets inutiles. Le stockage et les accès demandent une minimisation. Envoyez les identifiants et données nécessaires au contrat, sans cookies ni mots de passe. La queue, ses sauvegardes et ses interfaces d’administration deviennent elles aussi des surfaces de conservation des données.

Panne après effet

Les tests doivent simuler une réponse perdue après effet. La répétition doit être testée explicitement. Un test qui échoue avant toute écriture ne couvre pas le doublon critique. Simulez un effet réussi suivi d’une erreur d’acquittement et confirmez que la reprise conserve un seul résultat métier.

Atelier guidé : lire, expliquer et vérifier le code

// handle(PaymentCaptured $message)
$ledger->append($message->paymentId, $message->amount);
$email->sendReceipt($message->paymentId);
// aucune déduplication n’est définie dans l’exercice

Le handler d’exemple applique un effet avant l’acquittement. Rejouez le même message dans une base de test, puis comptez les écritures et les appels externes. La correction doit utiliser une identité d’opération stable et définir sa transaction. Pour une frontière externe, ajoutez un état durable permettant de réconcilier une réponse perdue.

Cela ajoute un effet sans résoudre le doublon. Retirer la trace ne protège pas les données. Les reprises peuvent répéter des effets déjà appliqués. Le type ne donne pas l’unicité d’exécution.

Travail pratique : Définissez clé et invalidation d’un cache de catalogue, puis concevez un handler supportant la répétition d’un message.

Critères de correction : Incluez les dimensions du résultat dans la clé et invalidez lors des changements pertinents. Pour le handler, enregistrez la clé métier traitée avec l’effet durable et testez une double livraison.

Outbox : rendre durable l’intention de publier

Écrire l’état SQL puis publier un événement crée une fenêtre : le commit peut réussir et la publication échouer. Publier avant commit inverse le risque, car un événement peut annoncer un état finalement annulé.

Écrivez changement d’état et ligne d’outbox dans la même transaction locale. Après commit, un relais lit cette intention durable et publie avec reprise. Cette stratégie ferme la perte de l’intention entre les deux écritures, sans fournir une transaction distribuée universelle entre base et broker.

Le relais peut publier puis perdre son acquittement, donc republier. Le consommateur doit être idempotent avec une identité d’événement et une transition durable cohérente. Testez panne après commit avant publication, puis panne après publication avant marquage de la ligne. Vérifiez qu’aucun événement n’est émis pour une transaction annulée et qu’une relivraison ne répète pas l’effet métier. Surveillez également retard et lignes bloquées pour rendre la reprise opérable.

Points de vigilance : La publication pourrait annoncer une capture locale ensuite annulée. L’intention durable est atomique avec l’état ; le relais peut republier, d’où l’idempotence en aval. Le processus peut mourir après le commit et avant le callback ou pendant la publication. Une réponse HTTP et un accusé du broker appartiennent à des échanges distincts.

Port de paiement : représenter attente et action requise

Un booléen success fusionne des états qui demandent des comportements différents. Un moyen de paiement peut nécessiter une action client, rester en traitement, être refusé ou atteindre un succès confirmé. Ramener attente à false encourage parfois une nouvelle tentative alors qu’un effet est déjà en cours.

Définissez un résultat typé avec état, référence prestataire et données nécessaires à l’action admise. Documentez transitions et acteurs qui peuvent les déclencher. Un adaptateur traduit les capacités du partenaire sans masquer la différence entre autorisé, capturé et encore en attente lorsque le cas d’usage en dépend.

Testez action requise puis reprise, notification répétée et événement arrivant hors ordre. La transition doit préserver les invariants et éviter de revenir d’un état final vers un état ancien par simple copie de webhook. L’interface doit afficher une attente honnête et retrouver l’état serveur, plutôt que considérer le callback navigateur comme une preuve définitive.

Points de vigilance : Cette réduction perd l’attente et peut déclencher une relance dangereuse. Le succès du transport ne prouve pas celui du paiement. Une opération longue ou asynchrone ne doit pas immobiliser une transaction SQL en attendant son résultat. Le contrat représente les états nécessaires au cas d’usage ; adapter les capacités propres aux partenaires sans les masquer.