Pollen ist das regelmäßige Anfragen nach Daten, so lange, bis das gewünschte Ergebnis da ist oder man sich entscheidet, das Pollen abzubrechen. Pollen ist im Zusammenhang mit Eventual Consistency sehr nützlich. Wenn ich einen Befehl abschicke, weiß ich auch nach einem ACK¹⁾ nicht, ob das Ergebnis in den Sichten, die ich mir angucken kann, bereits vorhanden ist.

Wenn mir somit der Empfang oder die Durchführung eines Befehls bestätigt wird, habe ich im Grunde lediglich die Möglichkeit danach zu pollen, ob das Ergebnis auch schon in den Sichten angekommen ist, bevor ich mir die Sichten angucke. Die Frage ist natürlich, wonach ich polle.

Die Lösung wird ähnlich sein wie die für die Idempotenz ID. Ich als Absender des Befehls²⁾ setze im Befehl eine Polling ID. Diese Polling ID wird in alle Ereignisse³⁾ geschrieben, die ein direktes Ergebnis dieses Befehls sind. Event Handlers und Sagas, die Ereignisse abfangen und als Reaktion auf diese neue Befehle absenden, übernehmen die Polling ID in die Befehle. Die Event Handler und Sagas haben keine eigene Verwendung für die Polling ID⁴⁾.

Die Polling ID ist recht wichtig. Wenn ich z.B. einen Report ausdrucken möchte, der alles, was ich erfasst und angegeben habe, beinhalten soll, dann möchte ich das erst machen nachdem alle Angaben auch im Report enthalten sind. Das Pollen kann aber erst gestartet werden, nachdem der Befehl bestätigt wurde. Bei unerwarteten Fehlern beim Bestätigen sollte der Befehl erneut geschickt werden, so lange, bis mir entweder mitgeteilt wurde, dass er fehlgeschlagen ist, oder dass er durchgeführt wurde. Dafür wird die Befehlsidempotenz verwendet. Erst danach kann das Pollen starten.

Da ich erst polle, nachdem ich weiß, dass der Befehl bestätigt wurde, weiß ich, dass ich schließlich⁵⁾ ein Ergebnis mit der Polling ID erhalten werde. Ich könnte also unendlich lang pollen. Wenn es zu lange dauert, sollte der Admin informiert werden, dass Ereignisse irgendwo in einer Pipeline hängen geblieben sind. Die Frage ist, woraus sich die Polling ID zusammen setzt.

Die Polling ID setzt sich zusammen aus einer einfachen GUID, der Aggregate ID des Befehls, einer Kontextbezeichung… to be continued. Da der Befehl ja bereits als idempotent erklärt wurde, kann als nächster Schritt die Eindeutigkeit der Polling ID überprüft werden. Wurde sie bereits vergeben, wird der Befehl mit DuplicatePollingID abgelehnt! Das mag streng erscheinen und nicht sehr effizient, aber wenn der Client bereit ist zu pollen, dann ist er auch bereit zu warten.

Die Prüfung auf die Eindeutigkeit der Polling ID kann nur im eigenen Kontext geschehen - aber