Anatomie einer Taxi-Buchung in Echtzeit

Echtzeit · 2 Min. Lesezeit · 11. August 2026

Ich habe das Backend für ein Taxi-Dispatch-System in Toronto gebaut, und das Nützlichste, was ich dir geben kann, ist kein Code. Es ist das Bild, das ich in jedem Anruf mit dem Team immer wieder gezeichnet habe:

Das ganze System auf einer Serviette: zwei Handys, ein Server in der Mitte, und ein Sprachanruf, der ihn komplett umgeht.

Die drei Entscheidungen, die zählen

WebSockets, kein Polling. Ein Fahrer sendet alle 2 Sekunden seinen Standort. Über HTTP bedeutet das eine neue Verbindung, Header und Auth bei jedem Signal. Über einen WebSocket ist es ein 30-Byte-Frame. Bei 200 Fahrern online ist das der ganze Unterschied.

Der Server macht nur das Matching, sonst nichts. Dispatch entscheidet, welcher Fahrer den Auftrag bekommt, und leitet Positionen weiter. Er trägt den Sprachanruf nicht.

Die Stimme läuft Peer-to-Peer. WebRTC braucht den Server nur einmal, für den Handshake (Nachrichten wie bei Pfeil 1 und 2, um Netzwerkadressen auszutauschen). Danach fließt Audio von Handy zu Handy. Null Bandbreitenkosten auf deiner Seite, geringere Latenz für sie.

Alles Echtzeitige in diesem System ist ein Fan-out kleiner Fakten: "Fahrer bewegt", "Auftrag angenommen", "Auto angekommen". Modelliert man es als Events und hält jedes Event winzig, bleibt die Architektur einfach, und einfach ist, was man um 2 Uhr nachts will, wenn ein Taxi verschwunden ist.

Der Stack für Neugierige: Laravel für API und Matching, WebSockets für den Live-Kanal, WebRTC für die Anrufe, und eine Warteschlange (siehe den ersten Artikel) für Belege und Benachrichtigungen.

Notizen der Leser

Noch keine Notizen. Die erste ist immer die mutigste.