Une commande affiche « annulée », une offre « suspendue » et un versement « corrigé ». Les tables courantes donnent ces états, mais personne ne sait expliquer quelle succession de décisions, de messages et de compensations les a produits. Après un incident, l’équipe assemble des logs expirés, des captures et des sauvegardes qui racontent chacune une histoire différente.
Le problème n’est pas l’absence de traces. Il vient de traces conçues pour diagnostiquer une exécution, prouver une action humaine ou restaurer une infrastructure, jamais pour recalculer un état métier. Tant que ces usages restent confondus, un replay peut dupliquer une commande, réactiver une offre interdite ou effacer la raison d’une compensation.
Le vrai enjeu consiste à conserver une suite d’événements métier suffisamment stable pour produire à nouveau les mêmes projections, avec les mêmes règles et les mêmes bornes. Contre-intuitivement, tout enregistrer ne rend pas la marketplace reconstructible : sans identité, ordre, version et invariant, un volume supérieur de logs augmente surtout l’ambiguïté.
La méthode suivante définit la frontière du journal, son enveloppe, ses politiques de concurrence, ses projections et ses preuves de replay. Elle vise une architecture exploitable par produit, opérations et ingénierie, sans remplacer le registre des décisions humaines ni la stratégie de sauvegarde. Le coût caché d’une histoire introuvable se mesure en charge support, en commandes examinées à la main, en délai de reprise et en marge exposée. Dans ce cas, l’arbitrage utile consiste à journaliser d’abord le domaine dont une mauvaise reconstruction produit l’impact business le plus élevé.
Notre accompagnement en scalabilité marketplace opérateur relie cette histoire métier aux files, capacités et plans de reprise. La page création de marketplace replace ce choix dans la conception globale du modèle, des parcours et de la gouvernance.
Pour qui un état marketplace reconstructible devient-il critique ?
Le besoin apparaît quand plusieurs services modifient le même agrégat, quand les messages arrivent de façon asynchrone ou quand une correction doit être expliquée plusieurs semaines après sa réalisation.
Reconnaître une histoire devenue introuvable
Une équipe est exposée lorsqu’elle ne peut répondre qu’en consultant l’état final, lorsque deux services attribuent des dates différentes à la même transition ou lorsque la résolution dépend encore des logs d’une instance précise.
Les commandes orphelines, stocks écrasés par une ancienne version, commissions recalculées sans origine et offres réapparues après suspension indiquent tous une perte de causalité.
Choisir les domaines qui justifient ce coût
Commande, paiement, versement, droit vendeur, stock réservé et décision de publication présentent souvent une valeur élevée. Une préférence d’affichage ou un cache facilement régénérable ne réclament pas le même niveau.
Le journal est un engagement durable. Il se réserve aux états dont la reconstruction réduit un risque métier, réglementaire ou opérationnel mesurable.
Séparer journal d’événements, audit humain, logs et sauvegarde
Ces quatre dispositifs peuvent partager des identifiants, mais ils répondent à des questions différentes. Les fusionner crée une source trop bavarde pour le métier et trop pauvre pour restaurer correctement.
Attribuer une responsabilité à chaque mémoire
Le journal décrit ce qui s’est produit dans le domaine. Le registre d’audit précise qui a décidé ou corrigé, les logs détaillent une exécution technique et la sauvegarde restitue un support après perte matérielle.
Un événement « OffreSuspendue » peut pointer vers une décision d’audit, un trace ID et un lot sauvegardé. Il ne copie pas l’intégralité de ces trois preuves.
Éviter la cannibalisation des usages
Le journal d’audit vendeur marketplace possède la traçabilité des décisions, corrections et reprises humaines. Ici, la question est différente : quels faits permettent à un programme de recalculer l’état métier ?
Une sauvegarde restaure également des données déjà projetées, éventuellement incohérentes. Elle protège la continuité technique, tandis que le journal rejouable protège la logique de transformation.
Écrire un contrat d’événement orienté fait métier
Un événement se nomme au passé et représente un fait accepté par le domaine : CommandeConfirmée, StockRéservé ou VersementCompensé. Il n’est ni une intention ni une commande à exécuter.
Définir une enveloppe minimale et stable
L’enveloppe porte event ID, aggregate ID, type, version de schéma, numéro de séquence, date métier, date d’enregistrement, acteur, correlation ID, causation ID et tenant. La charge utile contient uniquement les données nécessaires au fait.
Chaque champ possède une sémantique écrite. Une date d’enregistrement ne remplace jamais la date d’effet, et une corrélation ne devient pas l’identité métier.
Protéger les invariants avant l’écriture
Le domaine refuse une réservation négative, une seconde confirmation incompatible ou une compensation sans opération d’origine. L’événement confirme que la règle a été vérifiée.
La validation en aval ne suffit pas : une fois un fait publié, les projections et intégrations peuvent déjà l’avoir consommé.
Stabiliser identité, corrélation et causalité
La reconstruction repose sur des identités qui survivent aux migrations et aux retries. Un identifiant de ligne locale ou une position dans un fichier ne constitue pas une identité métier durable.
Choisir la frontière de l’agrégat
L’agrégat borne la cohérence et la séquence. Une commande peut posséder sa propre histoire, tandis que les mouvements de paiement et de versement gardent des journaux reliés mais indépendants.
Un agrégat trop large sérialise toute la marketplace ; trop fin, il déplace les invariants critiques dans des projections éventuellement tardives.
Relier un effet à sa cause
Le correlation ID rassemble une transaction distribuée. Le causation ID relie chaque événement au message ou à la décision qui l’a déclenché.
Cette chaîne distingue une annulation demandée par l’acheteur d’une compensation automatique après échec de réservation, même si les deux conduisent au même état courant.
Maîtriser ordre, concurrence et événements tardifs
Il n’existe généralement pas d’ordre global fiable. La conception doit garantir l’ordre là où l’invariant l’exige et tolérer le désordre ailleurs.
Utiliser une séquence par agrégat
Chaque écriture annonce la version attendue. Si deux acteurs partent de la version 12, un seul crée la version 13 ; l’autre relit, réévalue la règle et produit éventuellement une nouvelle décision.
Le verrou optimiste évite qu’une correction de prix et une suspension vendeur se remplacent silencieusement dans la projection finale.
Traiter le retard sans réécrire le passé
Un signal transporteur reçu après la livraison conserve sa date métier, mais il ne fait pas revenir le colis au statut précédent. La projection applique une règle de précédence explicite.
L’événement reste dans l’histoire pour expliquer le retard. Une correction compensatoire est préférable à une mutation silencieuse de l’ancien fait.
Construire des projections jetables et vérifiables
La projection transforme les événements en lecture adaptée : fiche commande, solde vendeur, disponibilité, timeline support ou indicateur financier. Elle n’est pas la source définitive.
Rendre chaque consommateur idempotent
Le projectionneur mémorise event ID et position. Recevoir deux fois le même événement ne double ni le stock, ni le montant, ni le compteur.
Une transaction lie l’application du changement et l’avancement du checkpoint. Sinon, un crash entre les deux crée un trou ou un doublon.
Publier la fraîcheur de la lecture
Chaque vue expose son retard, sa dernière position et sa version de code. L’interface peut alors distinguer un état à jour d’une projection momentanément en retard.
Une projection reconstruite en parallèle est comparée à l’ancienne avant bascule. Le trafic ne change que lorsque les invariants et les comptes concordent.
Accélérer la reconstruction avec des snapshots contrôlés
Rejouer dix années de mouvements à chaque lecture serait inutile. Un snapshot conserve un état dérivé à une position donnée, sans devenir une seconde vérité.
Créer un point d’accélération invalidable
Le snapshot porte aggregate ID, dernière séquence, version de structure, checksum et date. Le moteur le charge puis applique les événements suivants.
Si sa version ou son checksum est invalide, il est ignoré et régénéré. Aucun snapshot ne doit empêcher une reconstruction depuis l’origine.
Adapter la fréquence au coût réel
Un agrégat court n’en a pas besoin. Une commande très active peut en créer tous les cent événements ou lorsque le temps de chargement dépasse un seuil.
Le monitoring suit taux d’utilisation, durée de replay et échec de validation. Une fréquence fixe sans mesure ajoute du stockage sans garantir la performance.
Faire évoluer les schémas sans casser l’histoire
Les événements vivent plus longtemps que les services qui les produisent. Renommer un champ ou modifier une unité doit préserver la lecture de chaque version passée.
Préférer compatibilité et upcasting
Ajouter un champ optionnel est souvent sûr. Pour une rupture, un upcaster transforme l’ancienne représentation en modèle courant au moment de la lecture.
Le fait historique reste intact. Le code de transformation est testé avec des fixtures de chaque version et versionné comme une dépendance critique.
Utiliser un nouvel événement quand le sens change
Si « prix » passe d’un montant brut à une composition multi-taxes, conserver le même nom brouille la sémantique. Un type nouveau rend la rupture explicite.
Les projectionneurs acceptent les deux formes pendant la migration. Leur résultat est rapproché sur un corpus connu avant retrait de l’ancien producteur.
Concilier histoire immuable, confidentialité et rétention
Immuable ne signifie pas conserver toute donnée personnelle en clair pour toujours. Le journal sépare le fait durable des attributs identifiants soumis à suppression ou limitation.
Minimiser la charge utile dès la conception
Un événement référence un customer ID pseudonymisé plutôt que nom, adresse et contenu libre. Les détails nécessaires vivent dans un coffre à accès et rétention contrôlés.
Une suppression détruit ou anonymise la correspondance selon la politique validée, tout en préservant le fait comptable ou opérationnel qui doit rester démontrable.
Tracer les accès sans recopier les secrets
Les lecteurs sensibles sont authentifiés, autorisés et audités. Les exports appliquent filtrage de tenant, finalité et durée d’exposition.
Clés de chiffrement, rotation et révocation possèdent un runbook. La reconstructibilité ne justifie jamais un journal accessible comme un fichier de diagnostic ordinaire.
Rendre le replay sûr avant d’en avoir besoin
Un replay n’est pas une réémission aveugle vers tous les systèmes. Il reconstruit d’abord une cible isolée, avec des effets externes neutralisés et une borne connue.
Séparer calcul et effets de bord
Le moteur relit les faits vers une nouvelle projection sans renvoyer email, paiement, webhook ou commande logistique. Les adaptateurs externes restent désactivés.
En entrée figurent journal, version et position ; en sortie, une base candidate, un rapport d’écarts et des invariants. L’owner valide avant toute bascule.
Borner rollback et reprise
La bascule conserve ancienne projection, checkpoint et route de retour. Si le taux d’écart dépasse 0,1 % ou si un invariant critique échoue, le trafic revient immédiatement.
Le runbook précise instrumentation, monitoring, files, dépendances, seuils, journalisation et traçabilité. Un retry reprend au checkpoint sans réappliquer les effets déjà validés.
Prouver qu’un état reconstruit est fidèle
La réussite ne se résume pas à un job terminé. Elle exige égalité des comptes, respect des invariants et explication de chaque différence avec la lecture actuelle.
Comparer par cohortes et empreintes
Les équipes rapprochent nombre d’agrégats, totaux financiers, transitions interdites, séquences manquantes et checksums par tenant, période et domaine.
Une empreinte globale ne suffit pas. Les cohortes localisent une version ancienne, une partition incomplète ou un projectionneur qui interprète mal un événement.
Tester des histoires connues
Les fixtures couvrent création, modification concurrente, doublon, événement hors ordre, compensation, suppression d’identité, snapshot obsolète et évolution de schéma.
Chaque scénario fixe la séquence d’entrée et l’état final attendu. Le test échoue aussi si un événement inconnu est ignoré silencieusement.
Exploiter le journal pendant un incident marketplace
L’histoire accélère le diagnostic si elle permet de suivre une cause sans lancer immédiatement un replay. Les outils de lecture doivent rester sûrs et compréhensibles.
Reconstituer une chronologie lisible
Scénario 1 : 312 commandes restent payées sans confirmation. La corrélation montre un paiement accepté, puis un timeout avant CommandeConfirmée. Le journal prouve les commandes absentes au lieu de les chercher par différence entre deux bases.
L’équipe crée une compensation bornée aux agrégats sans événement terminal, teste dix cas et élargit seulement si zéro doublon et zéro divergence financière sont observés.
Refuser la réparation qui invente un passé
Scénario 2 : une projection de stock affiche 20 au lieu de 8 après un message tardif. L’opérateur n’édite pas la ligne courante ; il corrige la règle de précédence et reconstruit la cohorte.
Si plus de 0,1 % des références non concernées changent ou si une réservation devient négative, le rollback est immédiat et le périmètre reste en quarantaine.
Éviter les erreurs fréquentes de journalisation
Les erreurs les plus coûteuses consistent à enregistrer des commandes techniques comme des faits, à recopier des objets complets, à supposer un ordre global ou à corriger directement un événement passé.
Ne pas appeler événement une intention
« PublierOffre » demande une action ; « OffrePubliée » constate une sortie validée. Dans ce cas, le bon arbitrage conserve la commande pour le workflow et n’ajoute au journal que le fait accepté.
Si une commande échoue avant validation, alors aucun fait métier ne doit être inventé. Les logs gardent la tentative et son diagnostic.
Ne pas transformer le journal en base documentaire
Copier le profil vendeur complet dans chaque événement multiplie les données personnelles, les incompatibilités et le coût complet de rétention. Une référence stable et les valeurs réellement décisives suffisent.
Dans ce cas, l’arbitrage oppose commodité immédiate et dette durable. L’équipe refuse la duplication lorsque la reconstruction peut relire une donnée versionnée dans un référentiel gouverné.
Implémenter stockage, publication et responsabilités
Le dispositif associe un event store append-only, un mécanisme de publication fiable, des projectionneurs indépendants, un registre de schémas et une console de replay contrôlée.
Garantir écriture et diffusion atomiques
En entrée, une commande validée fournit aggregate ID et version attendue ; en sortie, l’événement et l’outbox sont écrits dans la même transaction. Un relay publie ensuite avec retry et idempotence.
L’owner du domaine possède le contrat, la plateforme possède stockage et queue, chaque équipe consommatrice possède son checkpoint. Le monitoring distingue retard de publication et retard de projection.
Préparer dépendances et modes dégradés
Une indisponibilité du broker ne doit pas perdre l’événement : l’outbox attend et alerte. Une saturation de projection ne bloque pas nécessairement l’écriture métier, mais sa fraîcheur devient visible.
Le runbook documente capacité disque, partitions, sauvegarde du journal, restauration, rotation des clés, schema registry et ordre de reprise des consommateurs.
Fixer des seuils de qualité pour le journal
Une architecture rejouable se pilote par ses garanties, pas seulement par son débit. Séquences, doublons, retard et incompatibilités doivent déclencher des décisions explicites.
Mesurer intégrité et disponibilité
Le tableau suit événement sans schéma connu, trou de séquence, conflit de version, âge de l’outbox, retard par projection et durée de reconstruction.
Un trou sur paiement ou commande bloque le déploiement. Un lag supérieur à cinq minutes sur une vue opérationnelle ouvre une dégradation visible plutôt qu’un état présenté comme frais.
Tester la restauration complète
Un exercice trimestriel restaure journal et clés, recharge un snapshot valide, rejoue la suite et compare les preuves. Le temps réel est rapproché de l’objectif de reprise.
Une sauvegarde non restaurée reste une hypothèse. De même, un journal jamais rejoué ne prouve pas qu’il peut reconstruire la marketplace le jour où cela compte.
Plan d’action : rendre un domaine reconstructible en six semaines
Le pilote choisit un seul domaine critique, par exemple la commande. Il ne migre pas toute la plateforme et ne promet pas encore un event sourcing généralisé.
La sortie exige une histoire définie, une projection candidate, un replay isolé, des écarts expliqués et un exercice de rollback réussi. Produit, opérations, sécurité et ingénierie partagent la décision.
Cadrer avant d’instrumenter
- À faire d’abord : cartographier invariants, événements, identités, décisions et états actuellement impossibles à expliquer.
- À différer : journal global, nouveaux dashboards et migration des domaines à faible risque.
- À refuser : copier des logs applicatifs, stocker des objets complets ou appeler sauvegarde une source rejouable.
La première semaine relit trente histoires réelles et écrit les faits au passé. La deuxième fixe enveloppe, agrégat, séquence, confidentialité, versions et ownership. Chaque ambiguïté est arbitrée avant de choisir le stockage.
La troisième semaine produit événements et outbox sur une cohorte miroir. Aucun effet externe ne dépend encore de ce flux ; l’équipe compare seulement complétude, ordre et causalité.
La quatrième construit une projection parallèle et rapproche cent agrégats, les totaux financiers et tous les invariants critiques. Tout écart sans explication bloque la suite.
Livrer par preuves successives
- Semaine 1 : borner le domaine, ses invariants et trente chronologies représentatives.
- Semaine 2 : signer contrats, versions, rétention, responsabilités et règles de concurrence.
- Semaine 3 : écrire journal et outbox en miroir, puis mesurer pertes, doublons et retard.
- Semaine 4 : reconstruire une projection isolée et expliquer chaque différence.
- Semaine 5 : tester snapshots, anciens schémas, événements tardifs, confidentialité et rollback.
- Semaine 6 : basculer une cohorte, exercer un incident et décider l’extension.
- Promouvoir uniquement avec zéro trou de séquence critique et zéro invariant violé.
- Conserver l’ancienne projection pendant toute la fenêtre de comparaison.
- Documenter le coût de replay, la capacité restante et la prochaine frontière.
Le seuil d’extension demande 100 % des agrégats critiques rapprochés, moins de 0,1 % d’écarts non critiques tous expliqués, un replay dans l’objectif de reprise et un rollback exécuté en moins de quinze minutes.
La sixième semaine se termine par une décision, pas par une démonstration technique. Si le journal réduit le temps de diagnostic et sécurise la correction sans augmenter l’exposition des données, le domaine suivant peut entrer dans la roadmap.
Relier journal rejouable, audit et observabilité sans doublon
La reconstruction appartient à l’architecture de l’état. Elle complète le journal d’audit vendeur marketplace, qui possède les preuves humaines et leurs motifs, sans reprendre son intention.
Elle nourrit également les SLI métier marketplace, qui transforment des faits en mesures de promesse. Le journal conserve l’histoire ; le SLI décide comment compter le service.
Gouverner les décisions humaines séparément
Le registre d’audit vendeur documente motif, décideur, périmètre et clôture. L’événement peut référencer cette décision, mais n’en devient pas la copie exhaustive.
Cette frontière protège la lisibilité : le programme rejoue des faits stables, tandis que les équipes relisent les arbitrages et leurs preuves.
Observer les promesses produites par l’histoire
Les SLI métier marketplace utilisent les événements pour compter occasions, réussites et délais. Ils ne remplacent pas le journal et ne redéfinissent pas ses contrats.
- Le journal conserve les faits nécessaires au recalcul.
- L’audit conserve la décision humaine et sa justification.
- Les SLI transforment ces faits en mesure de service gouvernée.
Conclusion : garder une histoire marketplace réellement rejouable
Un état courant indique le résultat, pas le chemin. Pour reconstruire, la marketplace doit conserver des faits métier identifiés, ordonnés par agrégat, versionnés et protégés par des invariants.
Logs, audit et sauvegardes restent indispensables, mais chacun possède une autre responsabilité. Leur corrélation renforce la preuve ; leur fusion crée une mémoire ambiguë.
Projections jetables, snapshots invalidables, upcasters testés et replays isolés transforment le journal en capacité opérationnelle. Les exercices réguliers prouvent cette capacité avant l’incident.
Pour concevoir cette architecture et la relier aux capacités du run, notre expertise en création et reprise de marketplace opérateur accompagne contrats, event store, projections, tests de replay et bascules jusqu’à un état réellement reconstructible.
