Bei Änderung auslösen, nicht bei Uhrzeit

Event-getriebenes Design feuert, wenn sich etwas ändert. Die Zustandsänderung ist das Event. Das Event ist der Auslöser.

Form 1: der atomare Übergang ersetzt den Reparatur-Job.

Wenn ein Zustandsübergang das System in einem defekten Zwischenzustand hinterlassen kann, liegt der Defekt im Übergang selbst, nicht in der Abwesenheit eines Reparatur-Jobs. Behebe den Übergang so, dass er atomar (oder transaktional) abläuft. Wenn der Übergang atomar abgeschlossen ist, existiert kein defekter Zustand. Der Reparatur-Job hat nichts zu reparieren.

# DEFECT: nicht-atomarer Übergang hinterlässt defekten Zustand
def close_pr_on_repo_private(pr_id):
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'   # Schritt 1: partieller Zustand
pr.save()                             # jetzt für Benutzer sichtbar
# ... weitere Schritte können fehlschlagen ...
pr.merge_status = 'not_applicable'
pr.save()                             # Schritt 2: nun konsistent
# Sidekiq-Job gleicht aus, falls Schritt 2 fehlschlägt

# FIX: atomarer Übergang; kein Zwischenzustand sichtbar
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()   # beide Felder werden atomar geschrieben; niemals halb geschrieben

Form 2: das inkrementelle Update ersetzt die vollständige Neuberechnung.

Ein Bericht, der von Grund auf neu berechnet wird, feuert, weil alte Daten + neue Daten = neues Ergebnis. Aber altes Ergebnis + Delta = dasselbe neue Ergebnis, inkrementell berechnet. Das Event: neue Daten sind eingetroffen. Der Trigger: aktualisiere nur das Aggregat für die neuen Daten.

# DEFECT: vollständige Neuberechnung nach Zeitplan
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()

# FIX: ereignisgesteuerte inkrementelle Aktualisierung
def on_order_placed(order):
order.user.total_purchases += order.amount   # nur Delta
order.user.save()

Das inkrementelle Update wird ausgelöst, wenn eine Bestellung eintrifft, nicht um 2 Uhr nachts. Es aktualisiert nur den betroffenen Benutzer. Es liest nur die neue Bestellung, nicht alle Bestellungen aller Zeiten. Der nächtliche Job verschwindet.

Warum Form 1 eine kaputte Transition offenbart

Ein Form-1-gemessenes Herz zeigt, dass ein Zustandsübergang unvollständig geblieben ist. Der Reparatur-Job existiert, weil ein Ingenieur einen kaputten Zustand bemerkt und einen Abgleichsmechanismus hinzugefügt hat, anstatt den Übergang zu reparieren. Der Reparatur-Job: ein Pflaster über einer kaputten Architekturentscheidung.

MOAD-0009 als Verstärker

MOAD-0009 verstärkt andere MOADs. Ein Zustandsreparatur-Job, der alle Datensätze scannt, um kaputten Zustand zu finden: MOAD-0001 (O(N)- oder O(N²)-Scan pro Job-Ausführung). Ein Report-Job, der alles kalt neu berechnet: MOAD-0005 (Cache-Stempelwede, wenn der Job startet und ein warmes Upstream trifft). MOAD-0009 schadet nicht nur allein; er liefert andere MOADs nach Plan.

Diagnose & Redesign

Ein Team führt einen nächtlichen Cron-Job um 2 Uhr nachts aus. Der Job scannt alle Bestellungen aller Benutzer und berechnet den Gesamtkaufbetrag jedes Benutzers von Grund auf neu. Der Job dauert 4 Stunden. Um 6 Uhr morgens zeigt das Dashboard frische Summen. Zwischen 2 Uhr und 6 Uhr morgens zeigt das Dashboard die Summen des Vortags.