Eure Fahrer-App muss im Faraday-Käfig funktionieren

Die nützlichste Übung, die wir für einen neuen Logistik-Kunden durchführen, ist der Aufzugstest. Das Telefon des Fahrers in den Frachtaufzug an der Laderampe nehmen. Türen schließen. Die App beobachten.

Wenn die App zu einem Spinner wird, einfriert, die aktuelle Position verliert oder — der häufigste Fehler — den Scan, den der Fahrer gerade durchgeführt hat, stillschweigend verwirft, ist die App nicht produktionsreif. Fahrer verbringen einen erheblichen Teil ihres Tages in Stahlboxen, Betongebäuden, ländlichen Funklöchern und Tunneln. Konnektivität ist keine Eigenschaft, die sie haben. Es ist eine Eigenschaft, die sie manchmal haben.

Das ist die eigentliche Einschränkung. Dafür zu bauen ist kein Premium-Engineering — es ist die einzige Art, die liefert.

Die drei Fehlermodi, die Teams immer treffen

Nach genug Logistik-Projekten tauchen drei Fehlermodi immer wieder auf.

Das optimistische Schreiben, das keines war. Der Fahrer scannt ein Paket. Die App zeigt "gescannt." Der Server hat den Scan wegen eines Netzwerkaussetzer nie empfangen. Der Fahrer glaubt, das Paket sei im System; das System weiß es nicht. Das Paket kommt an der nächsten Station an und niemand weiß, was damit zu tun ist. Die Ursache: Die App zeigte Erfolg basierend auf einer lokalen Aktion, ohne Bestätigung vom Server und ohne Möglichkeit für den Fahrer, den Unterschied zu erkennen.

Der Login, der ein Netzwerk braucht. Ein Fahrer erscheint zu Schichtbeginn und das Telefon hat seine Session verloren. Der Login-Bildschirm muss den Auth-Server anrufen. Der Fahrer steht auf dem Parkplatz, mit zwei Balken Empfang, die auf null sinken, sobald der LKW sich bewegt. Die Schicht kann nicht beginnen. Jede Minute davon ist bezahlte Zeit, und das Telefon des Disponenten klingelt bereits.

Die "später synchronisieren"-Warteschlange, die Daten verliert. Viele Teams bauen Offline-Unterstützung, indem sie Aktionen lokal einreihen und synchronisieren, wenn das Netzwerk zurückkehrt. Das funktioniert — bis die Warteschlange mehr wächst, als das Gerät halten kann, oder der Nutzer die App schließt und die Warteschlange verloren geht, oder der Sync-Code einen Bug hat und Einträge stillschweigend verwirft. Der Fahrer erledigt seinen Job korrekt. Die Daten kommen nicht an. Der Fahrer bekommt die Schuld.

Was Offline-first wirklich erfordert

Offline-first ist kein Feature, das man hinzufügt. Es ist eine Eigenschaft der Architektur — entweder ist die App von Tag eins darauf ausgerichtet, oder sie ist es nicht.

Die Form, die funktioniert:

Der lokale Speicher ist die Source of Truth für die Session. Wenn der Fahrer ein Paket scannt, wird der Scan sofort in einen dauerhaften lokalen Speicher geschrieben, und die UI liest aus diesem Speicher. Die Server-Synchronisierung ist ein separater Prozess, der läuft, wann immer er kann. Die UI wartet nicht auf den Server — sie zeigt den lokalen Zustand, der der echte Zustand ist, den der Fahrer erlebt.

Jede Aktion hat eine clientseitig generierte ID. UUIDs, auf dem Gerät generiert, bevor die Aktion ausgeführt wird. Das bedeutet, dieselbe Aktion kann beliebig oft wiederholt werden, ohne serverseitig Duplikate zu erzeugen — und die Aktion existiert im lokalen Speicher mit einer stabilen Identität, noch bevor der Server sie je gesehen hat.

Synchronisierung ist für den Nutzer sichtbar, nicht versteckt. Ein kleiner Indikator: "12 Aktionen ausstehend, zuletzt synchronisiert vor 4 Minuten." Fahrer empfinden das als beruhigend. Sie wollen wissen, ob ihre Arbeit erfasst wurde. Den Sync-Status im Namen von UX-Sauberkeit zu verstecken ist das, was zum "gescannt, aber eigentlich nicht"-Szenario führt.

Authentifizierungstoken haben eine lange Offline-Gültigkeit. Einmal einloggen, ein Token erhalten, das eine mehrtägige Offline-Periode übersteht. Das Token im Hintergrund erneuern, wann immer das Netzwerk verfügbar ist. Ein Netzwerkfehler bei der Token-Erneuerung als nicht-Ereignis behandeln — nur ein Token, das tatsächlich abgelaufen ist, ohne erneuert worden zu sein, sollte einen Re-Login erzwingen. Diese einzelne Änderung eliminiert den häufigsten Schichtstart-Fehler.

Was das für die Serverseite ändert

Offline-first wird meist als clientseitige Eigenschaft beschrieben. Es hat auch Konsequenzen für den Server.

Server-Endpunkte müssen idempotent sein. Der Client wird es erneut versuchen. Die Wiederholungen werden Tage nach dem Original stattfinden. Das Original wurde möglicherweise empfangen oder auch nicht. Der Endpunkt muss "Ich habe diese Aktion mit dieser clientseitig generierten ID bereits verarbeitet" elegant handhaben — das gleiche Ergebnis zurückgeben, anstatt ein Duplikat zu erstellen oder die Anfrage abzulehnen.

Zeit auf dem Server ist nicht dieselbe wie Zeit auf dem Client. Die Aktion wurde um 9:14 Uhr Fahrer-Ortszeit ausgeführt, aber der Server zeichnet sie um 11:47 Uhr auf, nachdem der Fahrer wieder in die Abdeckung zurückgekehrt ist. Jeder Datensatz braucht beide Zeitstempel. Berichte, die sie vermischen, werden das Unternehmen in die Irre führen.

Die Datenform muss eventually-consistent Änderungen tolerieren. Ein Fahrer könnte ein Paket als zugestellt markieren, dann könnte der Vorgesetzte es als Rückgabe markieren — bevor die Aktion des Fahrers synchronisiert hat. Die Konfliktauflösung muss bewusst gestaltet sein, nicht "der letzte Schreiber gewinnt durch Zufall." Meistens gilt: "Fahrer-Aktion hat Priorität innerhalb der Schicht, Vorgesetzten-Aktion hat Priorität danach" — aber das hängt vom Unternehmen ab.

Der pragmatische Test

Wenn ihr eine Logistikplattform bewertet — kaufen oder bauen — führt zuerst den Aufzugstest durch. Die App nehmen, das Telefon nehmen, die Aufzugstüren schließen, eine normale Aufgabe durchführen. Sehen, was passiert.

Die Plattformen, die diesen Test bestehen, sind normalerweise in Ordnung. Die Plattformen, die ihn nicht bestehen, werden ihn in der Produktion jeden Tag nicht bestehen — und sie werden das Netzwerk beschuldigen, wenn es passiert.