Beyond Bytes: Die vier Nachrichtentypen in Kafka verstehen

Szenario: Wenn sich die Adresse eines Benutzers ändert, könnte ein user.state Topic ein vollständiges Benutzerobjekt mit der neuen Adresse erhalten.

Zweck: Dieser Typ ist unschätzbar, wenn Ihr einfach den neuesten Zustand eines Objekts haben möchtet. Vielleicht möchtet Ihr den neuesten Zustand eines Benutzers an eine Datenbank eines anderen Services pushen. Dann nutzt diese Nachrichtenart.

Vorteile: Einfach zu verarbeiten, da jede Nachricht in sich geschlossen ist. Neue Consumer können schnell das vollständige Bild erhalten.

Nachteile: Hohes Datenvolumen, besonders bei großen Objekten mit häufigen, kleinen Änderungen. Es ist schwierig zu verstehen, was genau geändert wurde und warum, da die Nachricht nur den Endzustand enthält.

Szenario: Anstatt das gesamte Benutzerobjekt zu senden, sendet der Stammdaten-Service eine user.address.changes Nachricht, die nur die Benutzer-ID und die aktualisierte Adresse enthält.

Zweck: Delta-Nachrichten sind sehr effizient für häufige Updates, bei denen sich nur wenige Felder ändern. Ein konsumierender Service weiß sofort, was sich geändert hat und kann entsprechend handeln. Wenn er den vorherigen Zustand des Benutzers hat, kann er ihn leicht aktualisieren.

Vorteile: Höhere Effizienz durch minimales Datenvolumen. Eine klare und prägnante Darstellung dessen, was sich geändert hat.

Nachteile: Erfordert, dass der Consumer einen lokalen State pflegt, um ein vollständiges Bild zu erstellen. Wenn eine Nachricht verpasst wird, wird der lokale Zustand falsch sein. Es bietet auch keinen Einblick in das Warum der Änderung. Hat der Benutzer einen Tippfehler korrigiert oder ist er tatsächlich umgezogen?

Szenario: Wenn ein Benutzer tatsächlich umzieht, emittiert der Stammdaten-Service ein user.moved Event an ein Audit-Topic. Wenn das Backoffice einfach einen Tippfehler korrigiert, könnte es ein user.corrected Event emittieren. Die Event-Payload enthält die ID der geänderten Entität, den Event-Typ und die Payload. Die Payload ist normalerweise entweder eine State-Nachricht oder eine Delta-Nachricht.

Zweck: Events sind das Fundament ereignisgesteuerter Architekturen. Sie bieten ein unveränderliches Audit-Log von Geschäftsaktionen. Andere Services können auf dieses Event reagieren, ohne eng an den Producer gekoppelt zu sein. Zum Beispiel kann ein Audit-System das Event protokollieren, oder der Umzugs-Postkarten-Service kann eine Postkarte an den Benutzer senden, wenn der tatsächliche Umzug stattfindet.

Vorteile: Bietet eine semantische Bedeutung. Du weißt nicht nur, was sich geändert hat, sondern auch warum etwas passiert ist, was für komplexe Geschäftslogik entscheidend ist.

Nachteile: Kann zu "Event-Überlastung" führen, wenn ein separates Event für jede kleine Aktion erstellt wird. Eine konsumierende Anwendung benötigt ihre eigene Logik, um das Event zu verarbeiten und ihren Zustand zu aktualisieren, was komplexer ist als nur eine State-Nachricht anzuwenden.

Szenario: Nach dem Konsumieren des user.moved Events verarbeitet ein "Umzugs-Postkarten-Service" die Änderung und produziert einen Command an ein postcard.sender Topic. Der Befehl weist den Postkarten-Service an, eine Postkarte mit der neuen Adresse und einer personalisierten Nachricht zu senden.

Zweck: Commands werden für direkte, explizite Kommunikation zwischen Services verwendet. Der Ziel-Service kann sich auf seine Aufgabe konzentrieren, ohne die zugrundeliegende Geschäftslogik ("das Warum") hinter der Aktion verstehen zu müssen. Er führt einfach den Befehl aus.

Vorteile: Explizite und direkte Kommunikation. Der Zweck ist klar und die Logik des empfangenden Services ist unkompliziert. Der empfangende Service muss die zugrundeliegende Geschäftslogik ("das Warum") hinter der Aktion nicht verstehen.

Nachteile: Erzeugt eine engere Kopplung zwischen Producer und Consumer. Ein neuer Consumer kann einen Befehl nicht einfach für einen anderen Zweck wiederverwenden, was ihn weniger flexibel als ein Event macht.