Technik
Das Schwere ist nicht das Senden von Events
Ein Event zu veröffentlichen ist einfach. Sicherzustellen, dass jeder Dienst konsistent endet, auch wenn Nachrichten spät, doppelt oder in falscher Reihenfolge ankommen, ist die eigentliche Arbeit.
Wir setzen auf ein ereignisgetriebenes Design, in dem jeder Dienst seine Daten besitzt und auf Events anderer reagiert, statt in gemeinsame Tabellen zu greifen. Das hält die Dienste entkoppelt und lässt jeden für sich skalieren.
Die Details, die es zuverlässig machen, sind unspektakulär: idempotente Konsumenten, sodass ein wiederholtes Event keinen Schaden anrichtet, klare Verantwortung, sodass es eine einzige Quelle der Wahrheit gibt, und sorgfältiger Umgang mit Reihenfolge und Ausfall.
Die eigentliche Herausforderung
Konsistenz ist ein Versprechen, kein Standard
Ein Event zu senden ist leicht; sich auf die Wahrheit zu einigen ist schwer.
In einem verteilten System kann dieselbe Nachricht doppelt, in falscher Reihenfolge oder erst ankommen, wenn ein Dienst längst weiter ist. Die schwierige Arbeit ist nicht das Messaging, sondern ein Design, in dem keiner dieser Fälle Ihre Daten beschädigt.
Wir setzen auf Idempotenz und klare Zuständigkeit für jeden Zustand, sodass jeder Dienst ein Event sicher verarbeitet, im Wissen, dass ein Replay nichts Unerwünschtes ändert.
Wie wir die Wahrheit klar halten
Idempotente Handler
Dasselbe Event zweimal zu verarbeiten liefert dasselbe Ergebnis.
Eindeutige Zuständigkeit
Ein Dienst besitzt jede Tatsache, nichts muss abgeglichen werden.
Sichere Replays
Einen Stream neu zu verarbeiten ist Routine, kein Risiko.
Wie wir es konsistent halten
Die Prinzipien, die zählen
- 1
Klare Verantwortung
Jede Tatsache hat genau einen Dienst, der sie besitzt, sodass es nie einen Streit um die Wahrheit gibt.
- 2
Idempotente Konsumenten
Dasselbe Event zweimal zu verarbeiten ergibt dasselbe Ergebnis, sodass Wiederholungen und Duplikate sicher sind.
- 3
Ausfall behandeln
Wir gestalten für die Nachricht, die spät kommt, fehlschlägt oder nie ankommt, nicht nur den glücklichen Pfad.
- 4
Alles beobachten
Wenn etwas abdriftet, sehen wir es schnell und führen es auf die Ursache zurück.
Werkzeuge dienen den Prinzipien, nicht umgekehrt
Die konkrete Queue oder der Stream zählt weniger als die Disziplin drumherum. Bekommen Sie Verantwortung, Idempotenz und Ausfallbehandlung richtig hin, und die meisten Werkzeuge erledigen die Aufgabe gut.
Vertiefung
Die unspektakulären Entscheidungen hinter zuverlässigem Realtime
Die eigentliche Arbeit bei Realtime-Sync steckt nicht in der Socket-Schicht, sondern in der Entscheidung, was passiert, wenn zwei Änderungen kollidieren, ein Client nach einer Woche offline wieder synchronisiert oder ein Consumer hinter den Event-Strom zurückfällt. Diese Regeln legen wir zuerst fest und dokumentieren sie.
Events sind versioniert und idempotent: Eine doppelt zugestellte Nachricht ändert beim zweiten Mal nichts. Diese eine Eigenschaft eliminiert eine ganze Klasse von 3-Uhr-nachts-Vorfällen, weil Wiederholungen sicher statt riskant werden.
Auch das Fan-out begrenzen wir bewusst: Präsenz- und Tipp-Indikatoren dürfen verlustbehaftet sein, Finanzdaten nicht. Beide auf unterschiedliche Zustellgarantien zu verteilen hält den schnellen Pfad schnell, ohne mit den Zahlen zu spielen.
Wir bauen Software für Teams, deren Werkzeuge zur tatsächlichen Arbeitsweise passen sollen — Web, Mobile, KI und die Systeme, die alles verbinden. Hier schreiben wir über das, was wir dabei lernen.