Web Scraping verändert seinen Charakter, sobald eine Arbeitslast sich einer Milliarde Requests pro Monat nähert. In kleinem Maßstab besteht die technische Aufgabe darin, Daten aus einer Website zu extrahieren. Im Enterprise-Maßstab verschiebt sich das Problem in den Betrieb: Refresh-Pipelines im Zeitplan halten, Erfolgsquoten stabil halten, Anti-Bot-Druck abfedern und dafür sorgen, dass die Erfassungsschicht nie zum Engpass für alles Nachgelagerte wird.
Diese Fallstudie zeigt, wie eine führende US-amerikanische Intelligence-Plattform für Ferienunterkünfte den Crawlbase Enterprise Crawler in eine bestehende Datenplattform integriert hat, um rund eine Milliarde Requests pro Monat über Airbnb, Vrbo, Booking.com und regionale Reisemarktplätze hinweg zu tragen.
Die Analyseplattform des Unternehmens war bereits darauf ausgelegt, große Mengen an Marktplatzdaten aufzunehmen, zu normalisieren und auszuwerten. Statt dieses System neu zu entwerfen, ersetzte das Engineering-Team ausschließlich die Erfassungsschicht. Crawlbase übernahm die Aufgabe, Webdaten zuverlässig und in großem Maßstab zu beschaffen. Damit konnte sich der Kunde weiter auf das konzentrieren, was das Produkt tatsächlich differenziert: rohe Marktplatzdaten in Business Intelligence zu verwandeln.
5.52 Milliarden erfolgreiche Requests, im Schnitt 919 Millionen pro Monat und rund 30.6 Millionen pro Tag, bei einer durchschnittlichen Erfolgsquote von 99.96%. Das Monatsvolumen wuchs von November 2025 bis zum Höchstwert im März 2026 um 51% auf 1.04 Milliarden, und die monatliche Erfolgsquote fiel nie unter 99.78%.
Die Arbeitslast
Die Analyseplattform des Kunden bedient mehr als 2,300 professionelle Beherbergungsorganisationen in 220+ Ländern und Territorien. Sie kombiniert öffentliche Marktplatzdaten mit direkten Reservierungsdaten und erzeugt daraus Echtzeit-Marktinformationen für die Kurzzeitvermietungsbranche.
Anders als eine Analyseplattform, die auf einer einzigen Quelle aufsetzt, führt dieses System kontinuierlich zwei unabhängige Datenströme zusammen. Der erste stammt aus 65+ Integrationen mit Property-Management-Systemen (PMS) und deckt Reservierungs- und Betriebsdaten für rund 700,000 verwaltete Objekte ab. Der zweite stammt aus der großflächigen Erfassung öffentlicher Marktplatzdaten von Airbnb, Vrbo, Booking.com und regionalen Ferienvermietungsplattformen.
| Kennzahl | Wert |
|---|---|
| Geografische Abdeckung | 220+ Länder und Territorien |
| PMS-Integrationen | 65+ |
| Verwaltete Objekte | 700,000+ |
| Überwachte Airbnb-Inserate | 6.15 Millionen |
| Überwachte Vrbo-Inserate | 1.85 Millionen |
| Tägliche Crawl-Requests bei voller Abdeckung | ~33 Millionen |
| Monatliche Crawl-Requests | ~1 Milliarde |
Jeder Crawl speist eine Berechnung: Auslastung, Verfügbarkeit, Übernachtungspreise, Buchungsvorlaufzeiten, ADR, RevPAR und Wettbewerbsbenchmarks über Tausende lokaler Märkte hinweg. Inserate, Kalender, Preise und Verfügbarkeiten über Millionen von Objekten hinweg aufzufrischen, treibt den Tageswert auf rund 33 Millionen Requests und den Monatswert in Richtung einer Milliarde.
In dieser Größenordnung verändert sich die technische Herausforderung. Eine einzelne Inseratsseite zu erfassen, ist unkompliziert. Millionen davon kontinuierlich zu erfassen, jeden Refresh-Zyklus innerhalb eines strikten SLA-Fensters abzuschließen und die Daten schnell genug zu liefern, damit die nachgelagerte Analyse aktuell bleibt, ist ein völlig anderes Problem.
Zuverlässigkeit wiegt dann schwerer als Spitzendurchsatz. Jeder verzögerte Crawl, jedes Timeout und jeder unvollständige Job schlägt sich irgendwann als veraltete Marktinformation nieder, und das zeigt sich in den Auslastungstrends, Preisbenchmarks und Prognosemodellen, auf die sich Tausende professioneller Beherbergungsteams verlassen.
Wenn die Erfassungsschicht zum Engpass wird
Arbeitslasten dieser Größe legen Probleme offen, die in kleineren Scraping-Systemen kaum auftreten.
Als das Tagesvolumen in Richtung 33 Millionen Requests kletterte, geriet die Erfassungsinfrastruktur unter Druck. Die Crawl-Latenz stieg bei anhaltender Last, sodass große Refresh-Jobs zunehmend länger brauchten. Request-Timeouts häuften sich, besonders bei dynamischen Inseratsseiten und Verfügbarkeitskalendern von Airbnb und Vrbo. Einzelne Fehlschläge waren beherrschbar; über Millionen von Requests summierten sie sich zu unvollständigen Batches und verspäteten Refresh-Zyklen.
Eine selbst betriebene Proxy-Infrastruktur in dieser Größenordnung war ein Problem für sich. Die Routing-Performance schwankte zwischen Regionen, sporadische Netzwerkausfälle führten zu unvorhersehbaren Verzögerungen, und die Proxy-Pools gesund zu halten, erforderte ständige Aufmerksamkeit. Gleichzeitig verstärkten Airbnb und Vrbo laufend ihre Anti-Bot-Abwehr und senkten die effektive Crawl-Ausbeute durch Blocking, Fingerprinting und andere Erkennungsverfahren.
Die Folgen reichten weit über die Scraping-Schicht hinaus. Jeder verzögerte Crawl bedeutete, dass die nachgelagerte Analyse mit älteren Marktplatzdaten arbeitete. Verfügbarkeitskalender liefen auseinander, Preis-Snapshots hinkten den realen Marktbedingungen hinterher, und Wettbewerbsbenchmarks verloren an Aktualität, sobald ein Refresh-Fenster über sein Ziel hinausrutschte.
Der größte Kostenblock war Engineering-Zeit. Statt Analysefunktionen zu bauen, verbrachte das Team immer größere Teile seiner Woche damit, Crawler-Infrastruktur zu warten, Proxy-Pools zu tunen, fehlgeschlagene Jobs wiederherzustellen und Erfassungsproblemen nachzugehen. Nichts davon war ein Bug, den man beheben konnte. Es war die natürliche Folge davon, eine Erfassungsschicht in einer Größenordnung zu betreiben, in der planbare Zuverlässigkeit mehr zählt als roher Durchsatz.
Nur die Erfassungsschicht ersetzen
Die Analyseplattform war nie das Problem. Aufnahme, Normalisierung, Anreicherung und Reporting bewältigten große Mengen an Marktplatz- und Reservierungsdaten bereits mühelos. Nicht mithalten konnte die Schicht, die für das Abrufen dieser Informationen aus dem öffentlichen Web zuständig war.
Also isolierte das Team den Engpass und ersetzte ausschließlich die Crawl-Ausführung. Der Enterprise Crawler übernahm alles, was nötig ist, um Webdaten zuverlässig und in großem Maßstab abzurufen:
- Request-Routing.
- Rotierende Datacenter- und Residential-Proxy-Infrastruktur.
- JavaScript-Rendering für dynamische Seiten.
- Automatische Retries und Fehlerbehebung.
- Netzwerkresilienz.
- Anti-Bot-Handling über die unterstützten Marktplätze hinweg.
Alles nach der Erfassung blieb genau so, wie es war. Sobald Crawlbase eine Seite abgerufen hatte, führte die bestehende Pipeline des Kunden sie unverändert durch Validierung, Normalisierung, Anreicherung und Analyse.
Die Erfassung von der nachgelagerten Verarbeitung zu trennen, vereinfachte die Architektur. Crawlbase nahm die operative Komplexität von Request-Ausführung, Proxy-Rotation, Retries, Rendering und Anti-Bot-Resilienz auf sich, während die Infrastruktur des Kunden darauf fokussiert blieb, rohe Webdaten in Marktinformationen zu überführen.
Die Trennung erlaubte es außerdem, jede Schicht in ihrem eigenen Takt zu skalieren. Als das Crawl-Volumen wuchs, erforderten Verbesserungen an der Erfassung keine Änderungen mehr am Parsing, an der Speicherung oder an der Analyse. Es sind dieselben Prinzipien, die wir in unserem Leitfaden zur Architektur für Web Scraping in großem Maßstab behandeln, hier angewendet auf eine produktive Arbeitslast.
Skalierung in Richtung einer Milliarde Requests pro Monat
Der aussagekräftigste Test für eine Crawl-Infrastruktur ist ihr Verhalten, während die Arbeitslast wächst. Viele Systeme kommen mit moderatem Traffic gut zurecht und brauchen dann einen architektonischen Eingriff, sobald das Volumen steigt.
Über den Zeitraum von sechs Monaten wuchs das monatliche erfolgreiche Volumen von rund 687 Millionen Requests im November 2025 auf einen Höchstwert von 1.04 Milliarden im März 2026, ein Anstieg von etwa 51%. Der April schloss mit 990.7 Millionen ab und lag damit immer noch 44% über dem Startpunkt des Zeitfensters. Die Trendlinie über den Zeitraum entspricht rund +52.6 Millionen Requests pro Monat.
| Monat | Erfolgreiche Requests | Erfolgsquote |
|---|---|---|
| Nov 2025 | 686.7M | 100.00% |
| Dez 2025 | 889.8M | 100.00% |
| Jan 2026 | 1,015.8M | 100.00% |
| Feb 2026 | 894.8M | 99.98% |
| Mär 2026 | 1,037.5M | 99.78% |
| Apr 2026 | 990.7M | 100.00% |
Über das gesamte Zeitfenster ergibt das 5.52 Milliarden erfolgreiche Requests, im Schnitt 919 Millionen pro Monat und rund 30.6 Millionen pro Tag. Beachten Sie den Unterschied zwischen den beiden Tageswerten: Rund 33 Millionen Requests pro Tag kostet ein vollständiger Refresh-Zyklus bei voller Abdeckung, während 30.6 Millionen der gemessene Tagesdurchschnitt über sechs Monate realen Traffics ist.
Diese Zahlen sind mehr als Durchsatz. Jeder erfolgreiche Crawl speist Parsing-, Anreicherungs- und Analysesysteme, die Auslastungstrends, Preisintelligenz, Verfügbarkeitskalender, ADR, RevPAR und Wettbewerbsbenchmarks über Millionen überwachter Objekte hinweg erzeugen. Der Verlauf zeigt eine Erfassungsschicht, die zusätzliche Last aufnimmt, ohne zum limitierenden Faktor zu werden, und ohne dass die nachgelagerte Pipeline neu entworfen werden musste.
Zuverlässigkeit unter Dauerlast
Volumen zu skalieren ist nur die halbe Aufgabe. Eine Plattform, die Milliarden von Requests verarbeiten kann, nützt nur dann etwas, wenn die Ergebnisse verlässlich bleiben, während sich die Arbeitslast verschiebt.
Über dieselben sechs Monate blieb der Erfolg bemerkenswert konstant, trotz deutlicher Schwankungen im Monatsverkehr:
- 99.96% durchschnittliche Erfolgsquote der Requests.
- Monatlicher Erfolg zwischen 99.78% und 100.00%, eine Spanne von 0.22 Punkten.
- Nahezu eine Milliarde erfolgreiche Requests pro Monat über wechselnde Traffic-Muster hinweg.
Die Erfolgsquote übersetzt sich direkt in Analysequalität. Jeder abgeschlossene Request ist ein weiteres Stück Marktplatzdaten, das validiert, geparst, angereichert und in Auslastungsmodelle, Preisbenchmarks, Verfügbarkeitskalender und Prognose-Dashboards eingearbeitet werden kann. Fehlschläge hinterlassen Lücken, und Lücken mindern sowohl Aktualität als auch Vollständigkeit.
Die nützlichste Beobachtung ist, wie wenig sich die Zuverlässigkeit bewegte, während der Durchsatz um mehr als 50% wuchs. Die Erfassungsschicht tauschte keine Stabilität gegen Volumen. Für eine kontinuierlich aufgefrischte Analyseplattform ist diese Konstanz oft mehr wert als ein höherer Spitzenwert, denn jeden Erfassungszyklus pünktlich abzuschließen, hält nachgelagerte Systeme dabei, frische Daten zu verarbeiten, statt Infrastrukturrauschen auszugleichen.
Operative Auswirkungen
Weil jedes nachgelagerte System darauf angewiesen war, dass Marktplatzdaten pünktlich eintreffen, wirkten sich Verbesserungen in der Erfassungsstufe auf die gesamte Pipeline aus.
Verlässlichere Datenpipelines
Die unmittelbare Veränderung war Konstanz. Crawl-Jobs liefen über Airbnb, Vrbo, Booking.com und regionale Marktplätze hinweg planbar durch, sodass Refresh-Zyklen innerhalb ihrer Verarbeitungsfenster abschlossen, selbst als das Volumen weiter kletterte.
Nachgelagerte Aufnahme, Parsing und Normalisierung verbrachten weniger Zeit damit, verspätete oder unvollständige Batches auszugleichen, und mehr Zeit damit, frische Daten zu verarbeiten. Konstantere Refreshes bedeuteten aktuellere Auslastungstrends, Übernachtungspreise, ADR, RevPAR, Verfügbarkeitskalender, Buchungsvorlaufzeiten und Wettbewerbsbenchmarks. Das Ergebnis war nicht einfach schnelleres Scraping, sondern verlässlichere Business Intelligence.
Geringerer Betriebsaufwand
Die Erfassung auszulagern, senkte auch den Engineering-Aufwand für den Betrieb einer Scraping-Infrastruktur dieser Größe. Zeit, die zuvor in die Fehlersuche bei Crawler-Ausfällen, die Verwaltung von Proxies und die Wiederherstellung unvollständiger Jobs geflossen war, ging stattdessen in den Ausbau der Analyseabdeckung und die Unterstützung neuer Märkte.
Während überwachter Bestand, Kundenzahl und Crawl-Volumen wuchsen, trug die Erfassungsschicht weiterhin rund eine Milliarde Requests pro Monat, ohne erneut zu einem wiederkehrenden Engineering-Problem zu werden.
Erkenntnisse
Vier Prinzipien aus diesem Projekt gelten für jede Organisation, die groß angelegte Webdatensysteme aufbaut.
- Trennen Sie Erfassung von nachgelagerter Verarbeitung. Erfassung, Transformation, Speicherung und Analyse haben unterschiedliche Skalierungseigenschaften. Sie zu entkoppeln, lässt jede Schicht sich unabhängig weiterentwickeln und senkt die operative Komplexität.
- Optimieren Sie auf planbaren Abschluss, nicht auf Spitzendurchsatz. Für eine kontinuierlich aufgefrischte Plattform schlägt der zuverlässige Abschluss jedes Zyklus gelegentliche Leistungsspitzen.
- Behandeln Sie Anti-Bot-Resilienz als gemeinsame Infrastruktur. Im Enterprise-Maßstab sind Routing, Proxy-Verwaltung, Retries und Rendering Plattformfähigkeiten und keine Features einzelner Scraper.
- Messen Sie die operative Gesundheit, nicht nur das Volumen. Durchsatz allein sagt wenig aus. Erfolgsquoten, Abschlusskonstanz, Retry-Verhalten und Refresh-Latenz zeigen, ob eine Pipeline tatsächlich liefert.
Wenn Arbeitslasten in die Hunderte Millionen oder Milliarden Requests hineinwachsen, hängt der Erfolg weniger von einzelnen Scrapern ab als davon, Datenerfassung als produktive Infrastruktur zu behandeln. Eine Erfassungsschicht, die mitskaliert, lässt Engineering-Teams ihre Zeit in die Produkte und Erkenntnisse stecken, die Wert schaffen, statt in die Crawler darunter.
Die verwaltete Erfassungsschicht hinter diesem Projekt: Request-Routing, rotierende Datacenter- und Residential-Proxies, JavaScript-Rendering, automatische Retries und Anti-Bot-Handling, asynchron ausgeliefert an Ihren Webhook oder Cloud Storage. Milliarden Requests pro Monat, ohne eine eigene Crawler-Flotte zu betreiben. Sprechen Sie mit uns über Enterprise-Volumen, oder starten Sie im kostenlosen Tarif.
Häufig gestellte Fragen
Was bedeutet eine Milliarde Crawl-Requests pro Monat konkret?
Für diese Plattform sind das rund 33 Millionen Requests pro Tag bei voller Abdeckung, mit denen Inserate, Kalender, Preise und Verfügbarkeiten über 6.15 Millionen Airbnb-Inserate, 1.85 Millionen Vrbo-Inserate und weiteren Bestand auf Booking.com und regionalen Marktplätzen aufgefrischt werden. Über sechs gemessene Monate ergab das 5.52 Milliarden erfolgreiche Requests, im Schnitt 919 Millionen pro Monat.
Warum nur die Erfassungsschicht ersetzen statt der gesamten Pipeline?
Weil der Rest der Pipeline nicht der Engpass war. Aufnahme, Normalisierung, Anreicherung und Reporting bewältigten das Volumen bereits. Die Crawl-Ausführung zu isolieren, erlaubte dem Team, die schwächelnde Schicht zu reparieren, ohne Parsing, Speicherung oder Analyse anzufassen, und danach konnte jede Schicht in ihrem eigenen Takt skalieren.
Sinkt die Zuverlässigkeit, wenn das Crawl-Volumen steigt?
Hier nicht. Das Monatsvolumen wuchs über den Zeitraum um mehr als 50%, während die Erfolgsquote zwischen 99.78% und 100.00% blieb, ein Band von 0.22 Punkten, im Schnitt 99.96%. Für kontinuierlich aufgefrischte Analysen zählt diese Konstanz mehr als Spitzendurchsatz, denn ein verpasstes Refresh-Fenster zeigt sich als veraltete Marktdaten.
Wie wird Anti-Bot-Handling in dieser Größenordnung gelöst?
Als gemeinsame Infrastruktur statt als Logik pro Scraper. Request-Routing, Proxy-Rotation über Datacenter- und Residential-Pools, JavaScript-Rendering für dynamische Seiten und automatische Retries stecken alle im Enterprise Crawler. Einzelne Erfassungsjobs tragen daher keinen eigenen Bypass-Code und müssen nicht jedes Mal angepasst werden, wenn ein Marktplatz seine Abwehr ändert.
Was sollten Teams messen, um zu wissen, ob ihre Erfassungsschicht gesund ist?
Erfolgsquote, Abschlusskonstanz, Retry-Verhalten und Refresh-Latenz, nicht das Request-Volumen für sich allein. Der Durchsatz sagt nichts darüber aus, ob Refresh-Zyklen rechtzeitig fertig werden. Die nützliche Frage lautet, ob jeder Zyklus innerhalb seines Fensters bei stabiler Erfolgsquote abschließt.
Crawlen Sie jede Website im großen Maßstab, ohne gegen die Infrastruktur zu kämpfen.
Crawlbase übernimmt Proxys, Fingerprints und CAPTCHAs, damit Ihr Team Datenpipelines ausliefert, statt Crawl-Infrastruktur zu pflegen. 1.000 Anfragen kostenlos, keine Karte erforderlich.