Airhelp - WordPress Projekt | WPPoland

#AirHelp, Technologie für den größten Verfechter der Passagierrechte

Das Antragsformular ist das Herzstück dieses Projekts, und es arbeitet unter der unangenehmsten Bedingung, die man einem Formular zumuten kann: Es wird genau dann am stärksten genutzt, wenn die Systeme, von denen es Daten holt, selbst unter Last stehen. Ein Fluglotsenstreik oder ein Ausfall in der Abfertigung legt mehrere hundert Flüge lahm, und innerhalb einer Stunde trifft ein Vielfaches des üblichen Verkehrs auf dieselbe Seite. Dieselbe Störung belastet zugleich die Schnittstellen der Fluggesellschaften. Aus dieser Gleichzeitigkeit folgt der größte Teil der Architektur, die weiter unten beschrieben wird.

AirHelp wurde im Januar 2013 von Henrik Zillmer gegründet und hat seinen Sitz in Berlin. Rechtliche Grundlage in Europa ist die Verordnung 261/2004, außerhalb der Union kommen UK261, das Montrealer Übereinkommen, die brasilianische ANAC 400 und weitere nationale Regelwerke hinzu. Das Unternehmen hat über 13 Millionen Menschen geholfen, ihre Rechte zu verstehen und Entschädigungen für verspätete, annullierte oder überbuchte Flüge zu erhalten, vertritt sie in Verfahren gegen Fluggesellschaften und setzt sich auf Regierungsebene für faire Vorschriften ein.

Als Entwickler habe ich die Website konzipiert und umgesetzt und dabei ein fünfköpfiges Team als Team Pilot geleitet. Die Umsetzung dauerte rund sechs Wochen von der Anforderungsanalyse bis zur Veröffentlichung, Layout und Elementanordnung kamen vom Kunden.

#Das Antragsformular und sein Ausfallverhalten

Die Integration mit den Schnittstellen der Fluggesellschaften verursachte Verzögerungen bei Verkehrsspitzen. Gelöst wurde das über RabbitMQ, also asynchrone Verarbeitung der API-Anfragen, mit einem Rückfall auf statische, in Elasticsearch gecachte Daten bei Zeitüberschreitung.

Der Rückfall ist dabei die eigentliche Entscheidung. Ein Formular, das in diesem Moment eine Fehlermeldung zeigt, verliert einen Antrag von jemandem, der vollen Anspruch auf Entschädigung hat. Ein Formular, das die Flugnummer ohne sofortige Bestätigung annimmt und später prüft, verliert ihn nicht. Der Preis dafür ist nicht null: Es entstehen Anträge, die sich in der Nachprüfung als unbegründet erweisen, und jemand muss sie bearbeiten. Diese Abwägung gehört dem Fachbereich, nicht der Technik, und sie wurde bewusst zugunsten der Annahme entschieden.

Die Validierung folgt derselben Logik. Es liegt nahe, eine Flugnummer, die nicht zum Muster passt, sofort im Browser abzulehnen. In der Praxis unterscheiden sich die Muster zwischen den Fluggesellschaften, und der Passagier überträgt die Nummer von einem schräg fotografierten Bordkartenbild. Ein Hinweis, der das Absenden nicht blockiert, nimmt den Antrag derjenigen Person an, die eine Null mit einem Buchstaben verwechselt hat. Eine harte Validierung verwirft ihn, und niemand erfährt davon.

Der Formularzustand wird nach jedem Schritt lokal gespeichert. In einer Abflughalle ist der Verbindungsabbruch kein Randfall, sondern der Normalfall, und fünfzehn Minuten verlorener Eingaben bedeuten einen verlorenen Antrag. Die Kehrseite muss man benennen: Antragsdaten enthalten Flugnummer und personenbezogene Angaben, ihre Ablage im Browser verlangt eine eigene Löschroutine nach dem Absenden und eine klare Regel, wann ein liegengebliebener Entwurf verfällt. Ohne diese Regel wird aus einer Bequemlichkeit ein Datenschutzproblem.

#Ziel von AirHelp und seine Zielgruppe

Die Website richtet sich an zwei Gruppen, die fast nichts gemeinsam haben.

Die erste sitzt nach einer Annullierung im Terminal, am Telefon, oft im Roaming, in einem schwachen Netz, verärgert, mit nichts als einem Foto der Bordkarte. Diese Person kam nicht, um über das Unternehmen zu lesen, sondern um zu erfahren, ob ihr etwas zusteht, und zwar in zwei Schritten.

Die zweite kommt Monate nach dem Flug über eine Suchmaschine und sucht eine bestimmte rechtliche Auskunft. Dieser Verkehr ist gleichmäßig, gut cachebar, liest lange Texte und landet auf Seiten in 24 Sprachen.

Eine Plattform bedient beide Muster unter einer Domain. Was für die erste Gruppe richtig ist, minimales Markup, serverseitig gerendert, nichts, was das Formular blockiert, ist für die zweite verschenkt. Was für die zweite richtig ist, aggressives Caching am Netzrand, ist für die erste unbrauchbar, weil ein Antragsstatus per Definition persönlich ist.

Hinter den Inhalten stehen Kooperationen mit Kanzleien in 30 Ländern und ein Team von 700 Mitarbeitern, darunter die weltweit größte Gruppe von Anwälten für Flugrecht. Für die Website heißt das: Rechtstexte haben auf Kundenseite einen echten Eigentümer und durchlaufen eine Freigabe, bevor sie produktiv gehen. Das Inhaltsmodell musste diesen Ablauf tragen, nicht umgehen.

#24 Sprachen sind ein Rechtsproblem, kein Übersetzungsproblem

Ein Satz darüber, wie viel Entschädigung zusteht, ist nicht ein Satz in vierundzwanzig Fassungen. Es sind gut zwei Dutzend eigenständige rechtliche Aussagen, von denen viele nur innerhalb einer Grenze zutreffen. Ein Flug von Warschau nach London unterliegt nach dem Brexit einem anderen Regime als derselbe Flug innerhalb der Union, und ein Flug ab São Paulo folgt Regeln, die mit beidem nichts zu tun haben.

Daraus folgt für das Inhaltsmodell, dass jede Sprachvariante ein vollwertiges Dokument mit eigenem Freigabezyklus sein muss und kein Übersetzungsfeld am Original. Eine Variante ohne Prüfung durch eine Anwältin der betreffenden Jurisdiktion darf nicht stillschweigend auf Englisch zurückfallen, denn dann veröffentlicht die Seite eine fremde Rechtslage als die eigene. Sie muss stattdessen aus Navigation und hreflang verschwinden. Genau dieses Standardverhalten bekommen generische Mehrsprachigkeits-Plugins falsch, weil ihre Voreinstellung immer lautet, lieber irgendetwas zu zeigen als nichts.

Die Frontend-Architektur basiert auf Next.js mit Server-Side Rendering und unterstützt 24 Sprachen über i18n. Sie berücksichtigt WCAG 2.1 und ist für mobile Endgeräte optimiert. Serverseitiges Rendern ist hier keine Geschmacksfrage: Bei Rechtstexten, die in Dutzenden Märkten ranken sollen, und bei Mobilgeräten in schlechten Netzen würde eine Verlagerung des Seitenaufbaus in den Browser bedeuten, dass das schwächste Telefon im schlechtesten Netz die meiste Arbeit übernimmt.

#Technische Funktionalitäten von AirHelp

Der Entschädigungsprozess lädt Flugdaten dynamisch über GraphQL, spricht die Schnittstellen der Fluggesellschaften an und speichert den Antrag in einer mit AES-256 verschlüsselten PostgreSQL-Datenbank. Die Wahl von GraphQL statt mehrerer REST-Aufrufe hat einen konkreten Grund: Jeder Schritt des Formulars braucht einen anderen Ausschnitt desselben Flugdatensatzes. Unter REST endet das entweder im vollständigen Vorabladen oder in einer Anzahl von Anfragen, die mit der Zahl der Schritte wächst. Genau die Felder abzufragen, die der aktuelle Schritt darstellt, reduziert das auf einen Netzwerkumlauf pro Schritt, und auf einem Telefon im Roaming ist das ein spürbarer Unterschied.

Der Informationsbereich mit den Rechtsartikeln wird über eine REST API geladen, in Redis gecacht und in React gerendert. Die Trennung der beiden Schnittstellen ist beabsichtigt: Redaktionelle Inhalte sind für alle Besucher identisch und eignen sich für aggressives Caching, Antragsdaten eignen sich dafür überhaupt nicht. Beides hinter einer Schnittstelle zu führen hätte etwas Code gespart und die Möglichkeit gekostet, für beide getrennte Lebensdauern zu setzen.

Das Benutzer-Dashboard zeigt den Antragsstatus in Echtzeit über WebSocket, gecacht in Memcached. Die Abwägung sei benannt: Eine dauerhafte Verbindung verbraucht Serverressourcen, solange ein Tab offen ist, und ein Antragsstatus ändert sich vielleicht alle paar Wochen. Ein Abruf im Minutentakt wäre billiger und für die Information ausreichend. Für den offenen Kanal spricht das Verhalten an dem einen Tag, an dem sich der Status tatsächlich ändert, denn dann sitzt die Nutzerin auf dieser Seite und lädt sie von Hand neu, und jedes manuelle Neuladen kostet mehr als das Halten des Kanals.

Backups laufen automatisch auf Amazon S3, mit regionsübergreifender Replikation, Versionierung und Zstandard-Kompression. Die Versionierung wiegt hier schwerer als die Replikation. Replikation schützt gegen den Verlust eines Rechenzentrums, ein seltenes Ereignis. Versionierung schützt gegen das Überschreiben von Daten durch einen eigenen Fehler bei der Bereitstellung, ein häufiges Ereignis, und eine in drei Regionen replizierte Kopie ist dann schlicht derselbe Fehler in dreifacher Ausführung.

Beim technischen SEO geht es um Begriffe wie „Entschädigung bei verspätetem Flug”, um dynamisch erzeugte XML-Sitemaps und um beschleunigte Indexierung. Bei Rechtstexten, die sich nach jedem bedeutenden Urteil ändern, beschreibt eine einmal beim Build erzeugte Sitemap den Stand der Website schon nach einer Woche nicht mehr, deshalb wird sie aus dem aktuellen Datenbankstand gebaut.

#Weitere Engpässe und ihre Lösungen

Die Datenbankbelastung traf PostgreSQL. Die Antwort war Redis mit persistenter Speicherung für die häufigsten Abfragen und Sharding mit Lese-Replikaten auf Amazon RDS. Lese-Replikate haben einen Preis, den man leicht übersieht: Die Replikation ist asynchron, ein Lesezugriff unmittelbar nach dem Absenden sieht den Antrag also möglicherweise noch nicht. Die Nutzerin reicht ein und landet auf einer leeren Liste, was wie Datenverlust aussieht. Lesezugriffe direkt nach einem Schreibvorgang gehen deshalb auf die Primärinstanz, verteilt werden nur Pfade, die einige hundert Millisekunden Verzögerung vertragen.

Hohe Latenz bei Bildern traf mobile Geräte in Regionen mit schwacher Anbindung. Fastly mit Brotli-Kompression, WebP und Lazy Loading über die Intersection Observer API verkürzte die Auslieferung, geo-optimale Verteilung verkürzte den Weg. Der Gewinn aus dem Bildformat ist allerdings zweitrangig gegenüber dem Gewinn daraus, dass Bilder unterhalb des sichtbaren Bereichs nicht mehr mit dem gelesenen Text um Bandbreite konkurrieren.

Verzögerungen im Echtzeit-Dashboard traten bei 13 Millionen Nutzern auf. Kafka übernahm das Streaming mit serverseitigem Throttling, ein AWS ALB verteilt den Verkehr. Throttling ist der unscheinbarste und notwendigste Teil davon, denn ohne ihn belegt ein einzelner Client in einer Fehlerschleife einen Kanal, der allen anderen gehört.

Veralteten Cache löst Varnish mit maßgeschneidertem VCL, Purge über Webhooks und Edge Side Includes für dynamische Abschnitte, ergänzt durch URL-Versionierung. Die ESI beantworten eine konkrete Spannung: Eine Artikelseite ist auf dem größten Teil ihrer Fläche für alle identisch und hängt nur in einem kleinen Fragment davon ab, ob die Leserin einen offenen Antrag hat. Ohne diese Trennung entwertet das kleine Fragment das Caching der ganzen Seite.

Die Ressourcennachfrage in Spitzenzeiten deckt Auto-Scaling auf AWS EC2 mit CloudWatch ab, dazu Cloudflare Rate Limiting gegen übermäßigen Bot-Verkehr. Auto-Scaling hat eine Schwäche, die direkt aus dem Verkehrsverlauf dieses Geschäfts folgt: Es reagiert auf Last, die bereits eingetreten ist, und eine Welle nach Massenannullierungen baut sich in Minuten auf. Die Schwellen liegen deshalb niedriger, als eine Kostenrechnung an einem ruhigen Tag nahelegen würde, und dieser Puffer ist bewusst gekauft.

#Barrierefreiheit jenseits der Prüfliste

WCAG 2.1 auf einer Entschädigungsplattform ist nicht in erster Linie eine Frage von Kontrast und Alternativtexten. Die entscheidende barrierefreie Komponente ist das mehrstufige Formular, und darüber entscheiden genau die Dinge, die ein automatischer Test nicht erfasst: ob eine Fehlermeldung programmatisch mit dem Feld verknüpft ist, das sie betrifft, ob ein Schrittwechsel den Fokus auf die Überschrift des neuen Schritts setzt, ob der Fortschritt überhaupt angesagt wird. Ein Formular, das nach einem Validierungsfehler nach oben springt, ohne den Fokus mitzunehmen, ist für eine Tastaturnutzerin eine Schleife ohne Ausgang, und es besteht jeden automatischen Test.

Dazu kommt ein Punkt, der in diesem Projekt schwerer wiegt als in den meisten anderen: Die Zielgruppe befindet sich in einer Ausnahmesituation, oft unter Zeitdruck, häufig in einer Fremdsprache. Kognitive Zugänglichkeit ist hier kein Zusatz, sondern der eigentliche Maßstab. Konkret heißt das kurze Schritte mit einer Frage, Fehlermeldungen, die den nächsten Handgriff benennen statt einen Zustand zu beschreiben, und an keiner Stelle ein Zeitlimit, das einen halb ausgefüllten Antrag verfallen lässt.

#Verwendete Technologien

Yoast SEO verantwortet Metadaten, dynamische XML-Sitemaps und Benachrichtigungen an Suchmaschinen. UpdraftPlus sichert nach Amazon S3 mit Replikation und AES-256-Verschlüsselung. Cloudflare stellt den Netzrand mit Argo Smart Routing, Brotli-Kompression und DDoS-Schutz über Rate Limiting. Redis cacht im Arbeitsspeicher, nach Sessions, Formularen und Dashboard getrennt. Varnish cacht serverseitig mit eigenem VCL, Grace-Modus und ESI. Der Grace-Modus verdient einen eigenen Satz: Er liefert im Moment des Backend-Ausfalls eine leicht veraltete Seite statt eines Fehlers, und bei Verkehr, der in Wellen kommt, ist das der Unterschied zwischen langsam und nicht erreichbar.

Lighthouse prüft Core Web Vitals innerhalb der CI/CD-Strecke in Jenkins. RabbitMQ stellt Aufgaben wie API-Verarbeitung und E-Mail-Versand in die Warteschlange, mit Wiederholungen und Dead Letter Queue. Elasticsearch trägt die Flug- und Inhaltssuche mit Fuzzy Matching und Aggregation, und die Unschärfe ist hier Pflicht statt Kür: Flugnummern werden von Bordkartenfotos abgetippt, Flughafennamen in vierundzwanzig Sprachen auf zwanzig Arten geschrieben. Fastly verteilt Medien geografisch, Kafka trägt den Echtzeitstrom mit Partitionierung.

#Management und technischer Support

AirHelp verlangt fortlaufende Optimierung und Betreuung. Ich aktualisiere Kern und Plugins regelmäßig und teste in einer Testumgebung mit Backups auf Amazon S3. Die Testumgebung ist dabei eine Kopie der Produktion und keine leere Installation, und genau diese Unterscheidung macht den Test überhaupt aussagekräftig. Eine Abfrage, die gegen zweihundert Anträge sofort zurückkommt, kann gegen Millionen Datensätze um zwei Größenordnungen wachsen, und auf einer leeren Datenbank sieht das niemand. Dasselbe gilt für die Cache-Trefferquote, die sich nur an einer realen Verteilung der Einstiegsseiten messen lässt.

Cloudflare, Redis und Fastly tragen die Leistung bei globalem Verkehr, Varnish, RabbitMQ und Kafka stabilisieren die dynamischen Abläufe. Die Überwachung läuft über Elasticsearch und CloudWatch, SQL- und NoSQL-Abfragen werden gegen ihre Indizes geprüft, der Cache wird bei Inhaltsänderungen invalidiert. Das wichtigste Signal darin ist nicht die Antwortzeit, sondern die Cache-Trefferquote, denn bei einer Website dieses Zuschnitts führt jeder Fehltreffer die Anfrage zum Ursprung, gleichgültig wie gut der Ursprung abgestimmt ist.

Die Plattform lässt sich um ERP-Integrationen, ein Modul zur Fluganalyse oder einen Bereich für rechtliche Auswertungen erweitern. Jede dieser Erweiterungen läuft in denselben Konflikt, der sich durch das ganze Projekt zieht: Je mehr Inhalt davon abhängt, wer ihn ansieht, desto weniger lässt sich am Netzrand ausliefern, und ab diesem Punkt müssen die hier getroffenen Entscheidungen neu gerechnet statt übernommen werden.