Die Preis-API ist der schwierige Teil von Google Flights – nicht der Feed

Kurzfassung

Ein Preisfeed ist eine strukturierte Liste, die Sie regelmäßig aktualisieren. Die Preis-/Routing-API ist etwas anderes: Wenn ein Nutzer auf Google Flights eine konkrete Verbindung anklickt, ruft Google in diesem Moment Ihre API und erwartet eine exakte, buchbare Fare – inklusive Gepäck- und Gebührenlogik – in deutlich unter einer Sekunde. Das ist der Teil, an dem Integrationen scheitern.

Was Google aufruft und wann

Der Feed deckt die Fläche ab – viele Routen, viele Daten, grob aktuell. Sobald ein Reisender Interesse zeigt, will Google den genauen Preis für diese Verbindung, live. Die Antwort muss buchbar sein: dieselbe Fare, die im Checkout hält.

Warum das schwer ist

• Fare-Regeln und branded fares – Basic, Standard, Flex mit unterschiedlichen Gepäck-, Umbuchungs- und Stornoregeln.
• Zusammensetzung des Preises – Grundpreis, YQ/YR, Steuern pro Land, Servicegebühr, Zahlungsartaufschlag, Zusatzleistungen.
• Währung – Umrechnung und Rundung müssen exakt dem Checkout entsprechen.
• Verfügbarkeit – die Buchungsklasse muss im Moment der Antwort real existieren.
• Langsame Quellen – GDS- und NDC-Roundtrips dauern oft mehrere hundert Millisekunden, manchmal Sekunden.

Eine Architektur, die trägt

• Vorberechneter Fare-Cache für die häufigsten Strecken und Zeiträume, mit einer TTL, die an das Preisparitäts-Monitoring gekoppelt ist.
• Echtzeit-Validierung gegen die Quelle für alles, was nicht sicher im Cache liegt.
• Asynchrone Pipelines für Anreicherung (Zusatzleistungen, Steuern), damit der kritische Pfad kurz bleibt.
• Circuit Breaker und graceful degradation – wenn eine Quelle langsam wird, lieber eine leicht konservativere, valide Fare als ein Timeout.
• Idempotenz auf jedem Schritt, damit Retries nichts doppelt buchen oder doppelt bepreisen.

Latenzbudget

Bei einem Ziel von unter einer Sekunde end-to-end bleiben nach Netzwerk und Overhead vielleicht 400–600 ms für Ihre Logik. Das reicht für einen Cache-Treffer plus leichte Validierung – nicht für einen kalten GDS-Roundtrip pro Anfrage. Deshalb ist der Cache kein Nice-to-have, sondern die Grundlage.

Testen

Schattenverkehr (echte Anfragen parallel gegen die neue API spiegeln, Antworten vergleichen, nichts ausliefern) und Replay von aufgezeichnetem Traffic decken die Fälle auf, die synthetische Tests übersehen: seltene Airlines, ungewöhnliche Steuerkonstellationen, Feiertags-Peaks.

MartiGO in der Praxis

Für MartiGO betreiben wir genau diese Schicht seit 2021 in Produktion – Echtzeit-Preise direkt an Google Flights, mit über 35 Mio. Euro jährlichem Buchungsvolumen. Der harte Teil war nie der Feed, sondern die API, die unter Last exakt und schnell bleibt.

Nächster Schritt

Mehr zur Google-Flights- & Metasearch-Integration oder Scoping-Gespräch buchen.