Wie unsere Module den Rezlynx-API-Client absichern — Backoff mit Jitter, TTL-Cache 5 s, Circuit Breaker bei 429.
Jedes GuestlineHub-Modul erhält vom Kunden einen Rezlynx-API-Token (JWT, HS256). Der Token wird verschlüsselt (AES-256) in unserer Datenbank gespeichert und im Klartext ausschließlich in den flüchtigen Prozessspeicher geladen, wenn eine API-Anfrage ausgeführt wird.
Standardgrenze der Rezlynx-API: 60 Anfragen pro Minute und Token. Unsere Module implementieren dazu einen Token-Bucket auf Anwendungsebene, der Bursts bis 20 Anfragen pro Sekunde erlaubt, sofern die Minutensumme unter 55 bleibt (Puffer von 5). Damit vermeiden wir 429-Antworten in normalen Betriebssituationen.
Bei einer 429- oder 5xx-Antwort wartet der Client zunächst 1 Sekunde, dann 2, dann 4, dann 8 Sekunden — jeweils mit Jitter (±20 %) zur Vermeidung des Thundering-Herd-Problems. Nach dem vierten fehlgeschlagenen Versuch wird die Anfrage in eine Wiedervorlage-Warteschlange gestellt, die im Anschluss an ein 60-Sekunden-Ruhefenster erneut abgearbeitet wird.
Verfügbarkeits- und Ratenabfragen werden 5 Sekunden im Anwendungscache gehalten. Damit reduzieren sich Doppelabfragen bei paralleler Nutzung durch mehrere Kanäle. 5 Sekunden bewegen sich unterhalb der Aktualisierungsfrequenz jedes uns bekannten OTA-Extranets.
Wenn 20 % der Anfragen innerhalb von 60 Sekunden mit 5xx antworten, öffnet der Circuit Breaker: neue Anfragen werden für 90 Sekunden nicht mehr an die Rezlynx-API geschickt, sondern direkt mit einem Fallback beantwortet (letzter bekannter Stand oder Sperre neuer Verkäufe, je nach Modul-Konfiguration). Der Kunde wird per E-Mail benachrichtigt.
Jede API-Anfrage wird mit Anfrage-ID, Latenz, HTTP-Status und Backoff-Iteration protokolliert. Die Logs werden 30 Tage vorgehalten und dem Kunden auf Anfrage bereitgestellt. Aggregierte Kennzahlen (P50, P95, Fehlerquote je Endpunkt) sind im GuestlineHub-Kundenbereich sichtbar.