Warum Edge-PDF-Rendering ab 10.000 Rechnungen pro Tag zählt

Wenn Sie ein paar hundert PDFs pro Tag auf einer einzelnen Backend-Lambda oder einem kleinen Kubernetes-Pod rendern, ist die Architektur kaum entscheidend. Fast alles funktioniert. Fast alles ist schnell genug.

Bei Skalierung ändert sich das. Sobald Sie zehntausende Dokumente pro Tag ausgeben - was ungefähr jede E-Commerce-Plattform, jeder Logistik-Carrier, jeder BNPL-Service, Payroll-Anbieter oder jede Invoicing-Plattform mit auch nur moderater Traktion erreicht - beginnen drei Zahlen zu schmerzen:

1. Cold-Start-Latenz, weil irgendwo immer etwas kalt ist.
2. Regionale Latenz, weil Ihre Kunden nicht neben Ihrem Origin sitzen.
3. Compute pro Render, weil Sie ihn zehntausende Male pro Tag bezahlen.

Dieser Artikel geht durch, wie sich diese Punkte ab etwa 10.000 Renderings pro Tag verändern und warum Edge-deployte Renderer wie gPdf praktisch eine andere Lösungskategorie sind, nicht “dasselbe, nur schneller”.

1. Die Cold-Start-Steuer wächst mit Concurrency

Cold Starts sind nicht nur lästig. Sie sind eine Funktion Ihrer Concurrency-Kurve. Typischerweise läuft es so:

• Sie provisionieren N=10 warme Container auf Basis des Durchschnittstraffics.
• Ein 3x-Traffic-Spike trifft ein, etwa Black Friday, Payroll Day oder Quartalsende.
• 20 neue Container starten kalt, um die Spitze abzufangen. Jeder braucht 1,5 bis 2,5 Sekunden, um Chromium, Prince oder Ihre Runtime zu booten.
• Für diese 30 Sekunden bedienen diese neuen Container mit p99 = 2 Sekunden und ziehen den globalen p99 mit nach oben.
• Ihr Downstream-Timeout-Budget, vermutlich 5 bis 10 Sekunden für die gesamte Order-Pipeline, wird nun von PDF-Generierung aufgezehrt.

Das ist in Ordnung, wenn Ihr Traffic flach ist. Es ist brutal, wenn er spiky ist, und PDF-Traffic ist immer spiky: Rechnungen entstehen an Billing-Grenzen, Labels bei Carrier-Abholung, Statements zum Monatsende.

Edge-deployte Alternative: Ein Cloudflare Worker isolate startet kalt in 5 bis 20 ms, nicht in 1,5 bis 2,5 Sekunden. Es gibt keinen Container zum Hochfahren, keine JVM/V8 zum Initialisieren, keinen Browser zum Bootstrappen. Das WASM-Modul lädt in einen Prozess, der bereits lebt. Cold Start ist damit nichts mehr, worum Sie Ihre Architektur bauen müssen.

Bei gPdf liegt der schlechteste Cold Start, den wir in Benchmarks beobachtet haben, bei ungefähr 12 ms - und das nur beim ersten Request an ein frisch zugewiesenes isolate. Nachfolgende Requests im selben isolate überspringen selbst das.

2. Regionale Latenz ist real, auch bei “schnellen” Requests

Ein Round-trip von Sydney zu einem us-east-1 Origin kostet 200 ms, bevor Ihr Code irgendetwas tut. Von Sao Paulo zu eu-west-1 sind es etwa 190 ms. Von Mumbai zur US-East-Coast etwa 220 ms.

Das gilt für jede Richtung. Eine zentralisierte PDF-API mit 300 ms serverseitigem Render sieht aus Sicht eines Kunden in Sydney so aus:

client -> us-east  : 200 ms
us-east render     : 300 ms
us-east -> client  : 200 ms
total wall-clock   : 700 ms

Für einen interaktiven Ablauf wie “Rechnung vor dem Versand anzeigen” ist das schmerzhaft. Für einen volumenstarken Backend-Job fällt es kaum auf.

Edge-deployte Alternative: Cloudflare läuft in über 300 Städten. Der nächste Colo zu Ihrem Kunden in Sydney ist grob 5 ms entfernt. Derselbe Render wird zu:

client -> SYD colo : 5 ms
SYD render         : 4 ms
SYD -> client      : 5 ms
total wall-clock   : 14 ms

Das ist eine 50x Verbesserung für interaktive Flows. Für Backend-Jobs ist es meistens egal, aber interaktive PDF-Previews wie “zeige mir, wie das vor dem Versand aussieht” werden kostenlos statt hakelig.

Der versteckte Folgeeffekt: Wenn Ihre PDF-API am Edge läuft, können Sie benachbarte Logik ebenfalls dorthin verschieben - Checkout-PDF-Preview, Rate Limit, Auth-Check. Jedes Stück, das Sie an den Edge schieben, entfernt einen Round-trip aus dem Hot Path.

3. Compute pro Render ist die Rechnung, die leise wächst

Lambda-Kostenrechnung bei 100.000 Renderings pro Tag:

• Puppeteer mit etwa 600 ms Wall Time und 1024 MB Speicher: rund 240 USD/Monat nur für Compute, vor Egress.
• DocRaptor bei 89 USD pro 100.000-Seiten-Stufe: rund 2.670 USD/Monat bei 100.000/Tag, also 3 Mio./Monat.
• gPdf bei 5 USD pro 100.000-Seiten-Stufe: rund 150 USD/Monat bei 100.000/Tag. Oder ungefähr 5 USD/Monat, wenn Sie genau bei 100.000/Monat landen.

Die Kostenlücke verschwindet mit Skalierung nicht, sie wird größer. Bei 1 Mio. Renderings pro Tag:

• Puppeteer-Infrastruktur: rund 2.400 USD/Monat plus Betrieb und Rufbereitschaft
• DocRaptor: rund 26.700 USD/Monat
• gPdf: 1.500 USD/Monat pauschal in dieser Volumenlogik, wenn Sie Volumen auf dem öffentlichen Preisraster verhandeln

Eine häufige Reaktion lautet: “In der Praxis müssen die Einsparungen kleiner sein; irgendwo steckt etwas Verborgenes.” Nach unserer Erfahrung: nein. Der Kostentreiber in der PDF-Generierung ist der Compute-Footprint des Renderers. Wenn Sie einen 600-MB-Chromium-Prozess gegen ein 4-MB-WASM-Modul tauschen, sinken die Kosten pro Render grob um den Faktor 100, und Ihre Rechnung folgt.

Warum das funktioniert, ohne dass wir daran scheitern: Der zugrunde liegende Cloudflare-Workers-Bundled-Preis liegt bei etwa 0,50 USD pro Mio. Requests. Da unser Renderer pro Aufruf etwa 1,5 ms CPU nutzt, liegen die direkten Kosten pro Render tatsächlich im Sub-Cent-Bereich. Wir schlagen moderat auf, um ein tragfähiges Geschäft zu betreiben, und Sie sehen trotzdem die 18x-Lücke.

Was “edge-deployed” wirklich bringt

Drei Dinge, keines davon hat mit Marketingfolien zu tun:

Vorhersagbare Latenz unter jeder Last

Da es keinen Boot-Kostenblock pro Request gibt, bleiben p50 und p99 nah beieinander. Wir sehen p99 typischerweise innerhalb von 3x p50, selbst während einer Lastspitze. Bei Puppeteer kann p99 während Cold-Start-Stürmen 10x p50 erreichen.

Ein deploybares Artefakt, überall

Ein .wasm-Modul wird identisch in jeden Cloudflare Colo deployed. Es gibt keine Frage “ist der Sydney-Pool warm?” Jedes isolate bootet das Modul innerhalb von Millisekunden und bedient identisch. Operativ ist das wirklich einfacher als regionale Lambda-Concurrency-Reservierungen zu pflegen.

Ein Pfad zur Einbettung

Wenn Sie gPdf irgendwann innerhalb des Perimeters eines Kunden ausführen möchten - in dessen VPC, isoliertem Cluster oder air-gapped Intranet - funktioniert dasselbe WASM-Modul. Das ist der Unterschied zwischen “wir hosten SaaS” und “wir liefern Technologie, die überall läuft”.

Wo dieser Ansatz nicht passt

Edge ist keine kostenlose Magie. Es gibt Workloads, bei denen zentralisierte Infrastruktur gewinnt:

• Mehrsekunden-Renderings. Wenn ein einzelnes PDF 30 Sekunden braucht, etwa riesige Finanzberichte oder wissenschaftliche Reports, sind Sie mit einem langlebigen Container und persistentem Zustand besser bedient als mit CPU-Grenzen am Edge.
• Renderings, die andere Datenbanken brauchen. Wenn Ihr Render drei OLAP-Tabellen joinen muss, sollte der Renderer nah an der Datenbank sitzen, nicht am Edge. Lösung: JOIN ausführen, dann das JSON für den eigentlichen Render an den Edge schicken.
• Outputs mit Post-Processing. Watermarking, Signing, Archivierung: Wenn Ihre Post-Render-Pipeline mehrstufig und zustandsbehaftet ist, wird die Zustandslosigkeit des Edge-Renders eher Kostenpunkt als Vorteil.

Für alles andere - und das ist die große Mehrheit von B2B-Rechnungs-, Label- und Belegtraffic - gewinnt Edge auf jeder relevanten Achse.

Wann Sie Ihr aktuelles Setup nicht mehr tolerieren sollten

Eine einfache Checkliste. Wenn Sie drei Punkte abhaken können, ist die Migrationsrechnung gekippt:

• Ihre monatlichen PDF-Infrastrukturkosten überschreiten 300 USD.
• Ihre PDF-p99-Latenz liegt bei normalem Traffic über 800 ms.
• Sie hatten einen Cold-Start-Incident, der Kunden betroffen hat.
• Sie haben mehr als 4 Stunden mit fehlenden CJK-, RTL- oder Emoji-Glyphen verbracht.
• Sie erzeugen PDFs in einem interaktiven Flow, etwa Preview oder Download im Bildschirm.
• Sie betreiben mehr als eine geografische Region.

Die ersten drei Punkte zusammen bedeuten: Sie zahlen und leiden. Die nächsten drei bedeuten, dass ein zentralisierter Renderer Produktentscheidungen aktiv begrenzt, die Sie sonst treffen könnten.

Wenn Ihnen das bekannt vorkommt, rendert der Playground eine Beispielrechnung in Ihrem Browser in unter 5 ms. Lassen Sie ihn für sich sprechen.