Deine Message Queue garantiert At-least-once-Delivery. Was heißt das für den Consumer, den du schreibst?

Es heißt, Duplikate sind normal und nicht die Ausnahme, dein Consumer muss also idempotent sein. Leite einen stabilen Key aus der Message ab, schreib verarbeitete Keys in derselben Transaktion wie den Effekt, und behandle eine Wiederholung als No-op. Rechne außerdem mit Zustellung außer der Reihe und mit erneuter Zustellung nach einem Crash zwischen Arbeit und Acknowledgment. Exactly-once von Ende zu Ende gibt es über Systemgrenzen hinweg nicht; du bekommst At-least-once plus idempotente Verarbeitung.

Es heißt, ich bekomme dieselbe Message zweimal, meistens weil der Consumer die Arbeit gemacht hat und dann vor dem Acknowledgment gestorben ist, also stellt der Broker erneut zu. Der Consumer muss daher sicher zweimal mit derselben Eingabe laufen können. In der Praxis nehme ich eine stabile id aus der Message, und wenn ich den Effekt schreibe, schreibe ich die verarbeitete id in derselben Datenbanktransaktion, mit einem Unique Constraint. Kollidiert das Insert, weiß ich, dass ich das schon erledigt habe, und acknowledge, ohne die Arbeit zu wiederholen. Entscheidend ist, dass Dedupe-Eintrag und Effekt zusammen committen; schreibe ich sie getrennt, gibt es ein Fenster, in dem ich duplizieren kann. Ich gehe außerdem davon aus, dass die Reihenfolge nicht garantiert ist, Handler sind also so geschrieben, dass sie ein Update vor dem Create verkraften, meistens über den Entity-Key plus eine Versionsprüfung. Für Fehler nutze ich begrenzte Retries mit exponentiellem Backoff und Jitter, danach eine Dead Letter Queue mit Alert, denn eine Poison Message still ewig zu wiederholen ist genau der Weg, wie eine Queue über Nacht volläuft.