Zum Inhalt springen
LEX
Tastatur: / oder Befehl K zum Fragen oder Springen, Backtick öffnet das Terminal.

LEX · der Pass

Bon

Bon

#

Von
Zeit
Bestellung

Abschicken

DE · EN · ES

Zurück zum Lab

Werkzeuge07 / 12

TukTuk

Ein Pilotprojekt für eine lokale Fahrdienst-Plattform auf einer Insel

Status
Funktionsfähig, nicht veröffentlicht
Rolle
Konzeption und Entwicklung, von Anfang bis Ende
Für
Fahrgäste, Concierge-Personal, das für Gäste bucht, und Fahrer.

Problem

Kleine Tuk-Tuk-Flotten auf Inseln disponieren per Anruf und aus dem Gedächtnis. Ein Pilot braucht ein gemeinsames Live-Bild für Fahrgäste, Disponenten und Fahrer, ohne den Aufwand eines kompletten Ride-Hailing-Stacks.

TukTuk ist ein Pilotprojekt für eine Fahrdienst-Plattform aus einer Fahrgast-Web-App, einer Einsatzkonsole und einer Android-zuerst-Fahrer-App auf einem gemeinsamen Backend. Es läuft als lokale Demo und ist nicht im Einsatz.

Fallstudie

Die Fahrgast-App ist eine PWA, die Einsatzkonsole bedient Disponenten und Concierge-Schalter, und die Fahrer-App entsteht mit Expo und ist zuerst für Android ausgelegt. Alle drei sprechen mit einem Fastify- und PostgreSQL/PostGIS-Backend, Redis dient nur für Jobs und Verteilung.

Das Projekt ist ein pnpm-Workspace mit gemeinsamen Paketen für Verträge, Domänenlogik und Übersetzungen. Es ist eine lauffähige lokale Demo zum Prüfen der Idee, ohne realen Betrieb dahinter.

Architektur

Ein Fastify-Backend auf PostgreSQL mit PostGIS. Präsenz- und Dispositionszustand liegen in Postgres, Benachrichtigungen nutzen eine Outbox und ein Zustellbuch, und Invarianten werden in der Datenbank selbst erzwungen. Redis übernimmt nur Jobs und Verteilung.

Technische Entscheidungen

  1. Ein eigener Kern statt eines Forks eines bestehenden Ride-Hailing-Projekts.
  2. Präsenz- und Dispositionszustand in Postgres statt in einem Cache.
  3. Outbox plus Zustellbuch für Benachrichtigungen, damit keine verloren geht oder unbemerkt doppelt rausgeht.
  4. Invarianten werden in PostgreSQL erzwungen, nicht nur im Anwendungscode.

Herausforderungen & Abwägungen

Die Disposition unter Last korrekt zu halten. Eine Simulation mit 250 Fahrern, die Heartbeats senden, hat das Design geleitet.

Belegte Ergebnisse

  • p95 von 4,2 ms für Heartbeats bei 250 simulierten Fahrern
  • API-Suite: 237 bestandene Tests; insgesamt 55 Testdateien
  • Lauffähige lokale Demo, nicht im Einsatz

Die Status sind sachlich: Nichts wird fertiger dargestellt, als es ist.

Stack

Fragen oder springen

Gib eine Frage oder einen Namen ein. Die Navigation ist deterministisch — kein Chatbot.

Drücke / oder ⌘K