Cloudflare Queues: Hintergrundjobs Am Edge

Cloudflare Queues löst das Problem, auf das jede Serverless-Anwendung irgendwann stößt: Es kommt eine Anfrage herein, die Arbeit auslöst, auf die der Nutzer nicht warten sollte. Die Bestätigungsmail verschicken, den Upload skalieren, den Datensatz zu einem Drittanbieter synchronisieren. Auf einem klassischen Server übergeben Sie das an einen Hintergrundprozess. Auf Workers gibt es keinen Prozess, an den Sie es übergeben könnten.

Die üblichen Behelfslösungen sind schlechter, als sie wirken. Die Arbeit inline zu erledigen bedeutet, dass der Nutzer auf einen E-Mail-Anbieter wartet. Eine Anfrage an einen anderen Worker abzuschicken und nicht darauf zu warten verliert den Job immer dann, wenn die aufrufende Invocation zuerst endet. Keine der beiden Varianten übersteht den Ausfall eines Anbieters.

Was eine Queue Ihnen bringt: Dauerhaftigkeit und Wiederholungen, keine Geschwindigkeit. Der Producer schreibt eine Nachricht und kehrt sofort zurück, ein separater Consumer-Worker nimmt sie auf, und wenn der Consumer scheitert, geht die Nachricht zurück in die Queue statt ins Nichts. Das ist der gesamte Nutzen. Wenn Ihr Hintergrundjob es nicht verträgt, wiederholt zu werden, rettet Sie auch eine Queue nicht.

Wie die Teile zusammenspielen

Eine Queue hat zwei Enden, und beide sind Workers.

Der Producer ist ein beliebiger Worker mit einer Queue-Bindung. Er ruft send mit einem Nachrichteninhalt auf, und dieser Aufruf kehrt zurück, sobald die Nachricht dauerhaft gespeichert ist. Die Anfrage des Nutzers endet, ohne auf die eigentliche Arbeit zu warten.

Der Consumer ist ein Worker mit einem Queue-Handler. Cloudflare ruft ihn mit einem Stapel von Nachrichten auf, und der Handler bestätigt jede Nachricht, die er erfolgreich verarbeitet hat. Alles, was nicht bestätigt wird, wird erneut zugestellt.

Das Verhalten bei erneuter Zustellung ist der Teil, um den herum Sie entwerfen sollten. Eine Nachricht kann mehrfach ankommen, was bedeutet, dass Ihr Consumer idempotent sein muss. Eine Karte in einem Queue-Consumer ohne Idempotenzschlüssel zu belasten ist der sichere Weg zu Rückerstattungen. Eine E-Mail zweimal zu senden ist ärgerlich, zweimal Geld einzuziehen ist ein Support-Vorfall.

Eine Dead Letter Queue fängt Nachrichten auf, die wiederholt scheitern. Ohne sie wird eine dauerhaft defekte Nachricht so lange erneut zugestellt, bis ihre Versuche aufgebraucht sind, und verschwindet dann. Mit ihr landet sie an einer Stelle, an der Sie sie untersuchen können. Richten Sie das ein, bevor Sie es brauchen.

Was eine Operation tatsächlich kostet

Das Preismodell ist ungewöhnlich genug, um Teams aus dem Tritt zu bringen, denn abgerechnet wird nicht pro Nachricht.

Eine Operation wird je 64 KB Daten gezählt , die geschrieben, gelesen oder gelöscht werden. Eine Nachricht unter 64 KB, die normal zugestellt wird, kostet drei Operationen: einmal schreiben, einmal lesen, einmal löschen. Eine Nachricht von 127 KB kostet zwei Operationen pro Aktion, also sechs insgesamt für dieselbe einzelne Zustellung.

Wiederholungen ändern die Rechnung. Jede erneute Zustellung ist ein weiteres Lesen, und ein Schreibvorgang in die Dead Letter Queue ist ein weiteres Schreiben. Ein Consumer, der eine Nachricht fünfmal scheitern lässt, bevor sie durchgeht, kostet weit mehr als drei Operationen. Das ist ein guter Grund, einen instabilen Consumer zu reparieren, statt seine Zahl an Wiederholungen hochzusetzen.

Rechnen Sie mit Ihrem eigenen Traffic, bevor Sie annehmen, dass es günstig ist. Eine Million Nachrichten pro Monat zu je drei Operationen sind drei Millionen Operationen, was über dem bezahlten Kontingent liegt und rund achtzig Pence kostet. Das ist wirklich günstig. Zehn Millionen Nachrichten pro Tag sind ein anderes Gespräch.

Die Limits, die über die Eignung entscheiden

Aus Cloudflares Dokumentation zu den Queues-Limits , geprüft im August 2026.

Zwei davon wiegen schwerer als der Rest. Die Obergrenze von 128 KB pro Nachricht bedeutet, dass Sie keine Dateien in eine Queue legen. Sie legen einen Verweis in die Queue und die Datei in R2, was ohnehin die richtige Form ist. Der Backlog von 25 GB schützt Sie vor der stillen Katastrophe: Wenn Ihr Consumer an einem Freitag ausfällt und niemand es merkt, füllt sich die Queue und weist neue Nachrichten mit einem Speicherfehler zurück, statt sie klammheimlich zu verwerfen.

Der Durchsatz von 5.000 Nachrichten pro Sekunde ist großzügig, gilt aber pro Queue. Eine einzelne heiß laufende Queue ist ein Engpass, den Sie durch Sharding über mehrere Queues hinweg wegplanen können.

Wann Cloudflare Queues die falsche Antwort ist

Wenn die Arbeit wirklich synchron ist. Wenn der Nutzer das Ergebnis auf dem Bildschirm braucht, fügt eine Queue nur einen zusätzlichen Umweg und ein Polling-Problem hinzu. Erledigen Sie es inline und machen Sie es schnell.

Wenn Sie geordnete Verarbeitung mit Exactly-once brauchen. Queues liefert At-least-once. Alles, was strenge Reihenfolge oder Exactly-once-Semantik verlangt, braucht eine Koordination, die die Queue nicht bietet, und auf Cloudflare heißt das in der Regel ein Durable Object.

Wenn es ein geplanter Job ist und kein ausgelöster. Eine nächtliche Bereinigung braucht keine Queue. Ein Cron-Trigger, der einen Worker direkt aufruft, ist einfacher und hat weniger bewegliche Teile.

Wenn die Arbeit länger als 15 Minuten dauert. Ein Consumer, der über seine Laufzeitgrenze hinausläuft, wird mitten im Job beendet. Lange mehrstufige Prozesse wollen Cloudflare Workflows, das für dauerhafte Ausführung über mehrere Schritte gebaut ist, und keinen Queue-Consumer, der eine Viertelstunde lang Zustand halten soll.

Unser Leitfaden zum Aufbau einer Serverless-API mit Cloudflare Workers behandelt den Anfragepfad, der diese Jobs meist erzeugt, und Cloudflare Workers gegen AWS Lambda zeigt, wie sich das Ausführungsmodell von dem SQS-und-Lambda-Muster unterscheidet, mit dem die meisten Teams ankommen.

Wo Sie anfangen

Suchen Sie das eine Stück Arbeit in Ihrem Request-Handler, auf das der Nutzer nicht warten muss, und verschieben Sie nur dieses. Geben Sie ihm vom ersten Tag an eine Dead Letter Queue, machen Sie den Consumer idempotent, und beobachten Sie die Backlog-Metrik, statt anzunehmen, sie sei leer.

Mecanik entwirft und prüft Edge-Architekturen über unser Team für Softwareentwicklung , einschließlich des Teils, in dem jemand fragt, ob der Job überhaupt eine Queue braucht. Die meisten Systeme brauchen eine oder zwei, nicht eine pro Feature.

Siehe auch: Cloudflare Hyperdrive: Postgres vom Edge aus , Wie man 2026 eine Web-App baut: der UK-Entwicklerleitfaden , Cloudflare D1: eine serverlose SQL-Datenbank am Edge bauen und Cloudflare Workers AI: KI-Modelle 2026 am Edge ausführen .

Häufig gestellte Fragen

Was kostet Cloudflare Queues? Der Workers-Free-Plan enthält 10.000 Operationen pro Tag und der Paid-Plan eine Million Operationen pro Monat, weitere Operationen kosten 0,40 $ pro Million und Egress-Gebühren fallen keine an. Eine Operation wird je 64 KB gezählt, die geschrieben, gelesen oder gelöscht werden, eine normale Nachricht unter 64 KB kostet also insgesamt drei Operationen: einmal schreiben, einmal lesen und einmal löschen.

Was zählt bei Cloudflare Queues als Operation? Jeweils 64 KB an Daten, die geschrieben, gelesen oder gelöscht werden. Eine Nachricht unter 64 KB kostet eine Operation pro Aktion, eine Nachricht von 127 KB dagegen zwei pro Aktion. Jede Wiederholung fügt ein weiteres Lesen hinzu und ein Schreibvorgang in die Dead Letter Queue ein weiteres Schreiben, ein instabiler Consumer kostet also deutlich mehr als die drei Grundoperationen pro Nachricht.

Wie groß darf eine Nachricht in Cloudflare Queues sein? 128 KB pro Nachricht, wobei Batch-Sends auf 100 Nachrichten oder 256 KB insgesamt begrenzt sind. Wegen dieser Obergrenze legen Sie die Nutzlast in R2 oder einen anderen Objektspeicher und nur einen Verweis in die Queue, was unabhängig vom Limit das bessere Design ist.

Garantiert Cloudflare Queues eine Exactly-once-Zustellung? Nein. Die Zustellung ist At-least-once, eine Nachricht kann also mehrfach ankommen und Ihr Consumer muss idempotent sein. Eine Zahlung einzuziehen oder eine Gutschrift auszustellen, ohne einen Idempotenzschlüssel zu setzen, verdoppelt sich irgendwann. Strenge Reihenfolge oder Exactly-once-Semantik brauchen stattdessen ein Durable Object.

Wann sollte ich Cloudflare Queues nicht einsetzen? Wenn der Nutzer auf das Ergebnis wartet, wenn Sie strenge Reihenfolge oder Exactly-once-Verarbeitung brauchen, wenn der Job geplant statt ausgelöst ist und ein Cron-Trigger reicht, oder wenn die Arbeit länger als das Consumer-Limit von 15 Minuten läuft. Für den letzten Fall gibt es Cloudflare Workflows.