Event-driven Bestellsystem

Der Order-Service veröffentlicht Domain-Events auf einem Fanout-Exchange und ist damit fertig. Er kennt seine Empfänger nicht und ruft niemanden auf.

Der direkte Aufruf: nach der Statusänderung den Notification-Service und den Stats-Service anfragen. Das ist naheliegend, in einer Zeile zu lesen und liefert sofort Rückmeldung, ob die Zustellung geklappt hat. Es trägt genau so lange, bis der dritte Interessent dazukommt — ab dann bedeutet jeder neue Empfänger eine Änderung, einen Test und ein neues Deployment am Order-Service, obwohl sich an Bestellungen nichts geändert hat. Im Projekt ist die Abwesenheit dieser Kopplung nachprüfbar: Eine Suche nach den Namen der Consumer oder nach ausgehenden HTTP-Aufrufen im Order-Service liefert nichts.

Eventual Consistency. Nach dem 200 OK ist die Statistik noch nicht aktualisiert — wer unmittelbar danach liest, sieht einen alten Stand. Und ein Fehler im Consumer meldet sich nicht mehr beim Aufrufer: Er landet in einer Queue, die niemand ansieht, solange nichts sie überwacht. Wer so baut, kauft Entkopplung mit Beobachtbarkeit, und muss diese Beobachtbarkeit von Anfang an mit einplanen.

Nein. Jeder Dienst hält seine eigene Kopie des Message-DTO, obwohl die drei Kopien heute nahezu identisch sind.

Das gemeinsame Contracts-Paket, auf das alle drei Projekte verweisen. Es ist der Reflex jedes erfahrenen Entwicklers, es beseitigt sichtbare Duplikation und ein Compiler wacht darüber. Nur stellt es genau die Kopplung wieder her, die der Fanout-Exchange gerade aufgelöst hat: Ab dann hängen alle drei Dienste an einer gemeinsamen Version, und eine Änderung am Paket zwingt sie zu einem abgestimmten Deployment. Die Entkopplung wäre dann nur noch im Diagramm vorhanden, nicht mehr im Betrieb.

Ein neues Feld muss an drei Stellen nachgezogen werden, und nichts erzwingt das — kein Compilerfehler, kein Test, der von allein rot wird. Tragfähig ist das nur, weil die Consumer unbekannte Felder ignorieren und ein Consumer, der ein Feld nicht kennt, weiterläuft statt abzustürzen. Ohne diese Toleranz wäre die Entscheidung falsch.

Als lesbarer String — "Paid", "Shipped" — nicht als Ordinalzahl des Enums.

Die Zahl. Sie ist kompakter, schneller zu verarbeiten und die Vorgabe vieler Serialisierer. Sie koppelt aber jeden Consumer stillschweigend an die Reihenfolge des Enums im Order-Service. Wird dort später eine Zwischenstufe in den Lebenszyklus eingefügt, verschieben sich alle nachfolgenden Werte, und die Consumer werten ab diesem Moment falsch aus — ohne Ausnahme, ohne Logeintrag, ohne dass irgendwo etwas rot wird. Ein Fehler, der nicht auffällt, ist teurer als einer, der sofort auffällt.

Der Payload wird geringfügig größer, und ein Tippfehler im Statusnamen fällt erst zur Laufzeit auf statt beim Kompilieren. Das ist der Tausch: ein sichtbarer Fehler an einer klar benannten Stelle gegen einen unsichtbaren an jeder.

Zwei. Jeder Consumer bekommt seine eigene Queue, beide sind an denselben Exchange gebunden.

Die gemeinsame Queue, an der beide Consumer hängen. Sie wirkt sparsamer und sieht im Diagramm identisch aus. RabbitMQ verteilt die Nachrichten dann aber unter den Consumern, statt sie zu kopieren — das Competing-Consumers-Muster. Jeder sähe ungefähr die Hälfte des Stroms: Ein Teil der Bestellungen bekäme keine Mail, ein Teil fehlte in der Statistik, und beides ohne einen einzigen Fehler im Log. Dasselbe Bild, ein völlig anderes Verhalten.

Jede Queue puffert für sich. Ein Consumer, der über Nacht ausfällt, lässt seine Queue volllaufen, während die andere unauffällig weiterläuft — der Speicherverbrauch des Brokers wächst also an einer Stelle, die niemand ansieht. Zwei Queues heißt zwei Dinge, die überwacht werden müssen.