Caching & Monitoring

Fehlerbehandlung und Zustände bei leeren Ergebnissen: Fehlerbehandlung. HTTP-Fehler der Plattform und Wiederholungsversuche: Fehlerbehandlung.

Aktualität der Daten

Ticketergebnisse werden von der API bis zu 1 Stunde im Cache gehalten. Der Cache-Schlüssel ist das vollständige Abfragetupel: (origin, destination, date, passengers). Jede Änderung der Passagierzahl oder des Datums erzeugt einen separaten Cache-Eintrag und einen neuen API-Aufruf.

Offenlegung: Stellen Sie Preise immer als unverbindliche Momentaufnahmen des Marktes dar. Weisen Sie in der UI für Passagiere klar darauf hin, dass sich Preise zwischen Suche und Buchung ändern können (zum Beispiel: „Preise können sich bei der Buchung ändern. Bestätigen Sie den Tarif auf der Website der Fluggesellschaft.“).

Debounce

Oberflächen für die Ticketsuche lösen typischerweise bei jeder Änderung der Flughafen- oder Datumsauswahl eine Anfrage aus. Verzögern Sie Eingaben per Debounce um 300–500 ms, bevor Sie eine Anfrage senden, damit die API nicht mit unvollständigen Abfragen überflutet wird, während der Nutzer noch tippt.

import os
import time
import requests

HEADERS = {
    "X-RapidAPI-Key": os.getenv("RAPIDAPI_KEY", "YOUR_RAPIDAPI_KEY"),
    "X-RapidAPI-Host": "skylink-api.p.rapidapi.com",
}
BASE = "https://skylink-api.p.rapidapi.com"

_cache: dict[str, tuple[dict, float]] = {}
TTL = 3600  # 1 hour — matches API cache lifetime


def search_tickets_cached(
    origin: str,
    destination: str,
    date: str,
    passengers: int = 1,
) -> dict:
    """
    Cache-wrapped ticket search. TTL 1 hour, keyed on (origin, dest, date, passengers).
    Raises ValueError on 422. Returns full response dict including count and flights.
    """
    cache_key = f"tickets:{origin}:{destination}:{date}:{passengers}"
    cached = _cache.get(cache_key)
    if cached and time.time() < cached[1]:
        return cached[0]

    r = requests.get(
        f"{BASE}/tickets/search",
        headers=HEADERS,
        params={
            "origin": origin,
            "destination": destination,
            "date": date,
            "passengers": passengers,
        },
        timeout=(10, 15),
    )
    if r.status_code == 422:
        detail = r.json().get("detail", "validation error")
        raise ValueError(f"422 Unprocessable: {detail}")
    r.raise_for_status()

    data = r.json()
    _cache[cache_key] = (data, time.time() + TTL)
    return data


if __name__ == "__main__":
    result = search_tickets_cached("JFK", "LAX", date="2026-09-15", passengers=1)
    flights = result.get("flights", [])
    print(f"Found {result.get('count', 0)} option(s).")
    if flights:
        cheapest = flights[0]
        duration = cheapest.get("total_duration_min", 0)
        print(
            f"Cheapest: ${cheapest.get('price_usd', 0):.2f}  ·  "
            f"{duration // 60}h {duration % 60:02d}m"
        )
        print("Prices may change at booking.")

    result2 = search_tickets_cached("JFK", "LAX", date="2026-09-15", passengers=1)
    print("Cache hit:", result2 is result)

Ersetzen Sie im Produktivbetrieb den Dict-basierten Cache durch Redis oder Memcached, damit der Cache Neustarts übersteht und von allen Instanzen gemeinsam genutzt wird.

Rate Limits

Bei einer TTL von 1 Stunde pro Tupel (origin, destination, date, passengers) verbraucht jede eindeutige Suche höchstens einen API-Aufruf pro Stunde. Füllen Sie bei Abläufen mit hohem Verkehrsaufkommen den Cache in verkehrsarmen Zeiten vorab mit den häufigsten Routen.

Monitoring

Protokollieren Sie bei jeder Ticketsuche:

• origin, destination, date, passengers
• status_code
• elapsed_ms
• count (aus der Antwort — nützlich, um den Anteil von Suchen ohne Verfügbarkeit zu verfolgen)
• cache_hit (boolean)
• quota_remaining (aus X-RateLimit-Requests-Remaining)

Alarmieren bei:

• sprunghaftem Anstieg des Anteils von count: 0 — kann auf einen fehlerhaften Datumsbereich oder ein Problem mit Query-Parametern hindeuten
• status = 429 mehr als zweimal innerhalb von 5 Minuten — erhöhen Sie die TTL oder drosseln Sie parallele Suchen
• wiederholt elapsed_ms > 5000 — erwägen Sie einen kürzeren Timeout mit einer Fallback-Meldung „Bitte erneut versuchen“
• quota_remaining < 200 — das monatliche Limit ist fast erreicht; verlängern Sie die TTLs oder reduzieren Sie die Anzahl eindeutiger Suchen

Siehe auch: Flugtickets · Flughafensuche · Fehlerbehandlung · Fehlerbehandlung