Idempotente Background-Jobs entwerfen: Retries, Locks und die Illusion von Exactly-Once

Jedes Queueing-System, das du einsetzen wirst — SQS, RabbitMQ, BullMQ, Sidekiq, Pub/Sub — verspricht "at-least-once"-Zustellung. Keines verspricht exactly-once, denn exactly-once-Zustellung in einem verteilten System ist nachweislich unmöglich, ohne dass der Consumer mitspielt. Das Netzwerk kann einen Ack verschlucken. Ein Worker kann abstürzen, nachdem er die Arbeit erledigt, aber bevor er sie bestätigt hat. Ein Retry kann feuern, während der ursprüngliche Versuch noch läuft.

Die unbequeme Wahrheit: Die Zustellgarantie deiner Queue ist nicht dein Problem. Das Verhalten deines Job-Handlers bei doppelter Ausführung schon. Wenn du dafür designst, dass "das hier mehr als einmal läuft, manchmal sogar gleichzeitig", wird exactly-once-Verhalten erreichbar — obwohl exactly-once-Zustellung nie erreichbar sein wird.