Déclencher sur le changement, pas sur l’horloge

Une conception pilotée par les événements se déclenche lorsqu’un élément change. Le changement d’état constitue l’événement. L’événement est le déclencheur.

Forme 1 : la transition atomique remplace la tâche de réparation.

Si une transition d’état peut laisser le système dans un état intermédiaire défectueux, le défaut réside dans la transition, et non dans l’absence d’une tâche de réparation. Corrigez la transition pour qu’elle s’exécute de manière atomique (ou transactionnelle). Lorsque la transition s’exécute de manière atomique, l’état défectueux n’existe jamais. La tâche de réparation n’a rien à réparer.

# DÉFAUT : transition non atomique laissant un état défectueux
def close_pr_on_repo_private(pr_id):
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'   # étape 1 : état partiel
pr.save()                             # visible aux utilisateurs MAINTENANT
# ... d'autres étapes peuvent échouer ...
pr.merge_status = 'not_applicable'
pr.save()                             # étape 2 : maintenant cohérent
# Job Sidekiq réconcilie si l'étape 2 échoue

# CORRECTION : transition atomique ; aucun état intermédiaire visible
def close_pr_on_repo_private(pr_id):
with db.transaction():
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'
pr.merge_status = 'not_applicable'
pr.save()   # les deux champs sont enregistrés de manière atomique ; jamais d’écriture partielle

Forme 2 : la mise à jour incrémentale remplace le recalcul complet.

Un rapport qui recalcule à partir de zéro se déclenche parce que anciennes données + nouvelles données = nouveau résultat. Mais ancien résultat + delta = même nouveau résultat, calculé de façon incrémentale. L’événement : arrivée de nouvelles données. Le déclencheur : mettre à jour l’agrégat uniquement pour les nouvelles données.

# DÉFAUT : recalcul complet planifié
def nightly_totals_job():
for user in all_users():
total = sum(o.amount for o in user.orders)  # scan all time
user.total_purchases = total
user.save()

# CORRECTION : mise à jour incrémentielle pilotée par événements
def on_order_placed(order):
order.user.total_purchases += order.amount   # delta uniquement
order.user.save()

La mise à jour incrémentielle se déclenche lorsqu’une commande arrive, pas à 2 h du matin. Elle met à jour uniquement l’utilisateur concerné. Elle lit uniquement la nouvelle commande, pas toutes les commandes de tous les temps. Le job nocturne disparaît.

Pourquoi le Formulaire 1 révèle une transition cassée

Un Form 1 Metered Heart révèle qu’une transition d’état est restée incomplète. Le job de réparation existe parce qu’un ingénieur a constaté un état cassé et a ajouté un mécanisme de réconciliation plutôt que de corriger la transition. Le job de réparation : un patch sur une décision architecturale défaillante.

MOAD-0009 en tant qu’amplificateur

MOAD-0009 amplifie les autres MOAD. Un job de réparation d’état qui scanne tous les enregistrements pour trouver l’état cassé : MOAD-0001 (scan O(N) ou O(N²) à chaque exécution du job). Un job de rapport qui recalcule tout à froid : MOAD-0005 (stampede de cache lorsque le job démarre et interroge un amont chaud). MOAD-0009 ne nuit pas seulement par lui-même ; il délivre les autres MOAD selon un planning.

Diagnostiquer & Redesigner

Une équipe exécute un cron job nocturne à 2 h du matin. Le job scanne toutes les commandes de tous les utilisateurs et recalcule de zéro le montant total des achats de chaque utilisateur. Le job prend 4 heures. À 6 h du matin, le tableau de bord affiche des totaux frais. Entre 2 h et 6 h du matin, le tableau de bord affiche les totaux de la veille.