Wie designst du einen Consumer für eine Queue mit At-least-once-Zustellung?

Geh davon aus, dass jede Message mehr als einmal ankommen kann, und mach die Verarbeitung idempotent. Leit einen stabilen Key aus der Message ab und prüf und speicher ihn entweder vor der Aktion in einem Store, oder nutz einen Conditional Write, sodass eine Wiederholung ein No-op ist. Setz das Visibility Timeout über deine schlimmste Verarbeitungszeit, verlänger es für lange Jobs, und schick Messages nach ein paar Fehlversuchen in eine Dead Letter Queue, damit Poison Messages den Fortschritt nicht blockieren.

Ich starte mit der Annahme, dass jede Message irgendwann mindestens zweimal ankommt, meistens weil ein Consumer langsam war und das Visibility Timeout ablief, während die Arbeit schon committet war. Der Consumer muss also idempotent sein, und ich will das konkret statt als Absichtserklärung. Meistens ist das ein Idempotenz-Key aus der Message, entweder eine ID, die der Producer gesetzt hat, oder ein Hash des bedeutungstragenden Inhalts, festgehalten in einer Tabelle mit Unique Constraint innerhalb derselben Transaktion wie die Arbeit. Wenn das Insert kollidiert, haben wir das schon gemacht, also acknowledgen und weiter. Wo der Effekt ein Write in einen Store ist, nehme ich lieber ein Conditional Update, dann landet zweimaliges Anwenden im selben Zustand. Operativ muss das Visibility Timeout über der langsamsten realistischen Verarbeitungszeit liegen, und bei wirklich langen Jobs verlängere ich das Lease unterwegs, statt ein riesiges globales Timeout zu setzen. Fehler werden mit exponentiellem Backoff und Jitter wiederholt, und nach wenigen Versuchen geht die Message mit angehängtem Fehler in eine Dead Letter Queue, damit eine schlechte Message nie den Rest blockiert.