Anatomie d'une réservation de taxi en temps réel

J'ai construit le backend d'un système de réservation de taxis à Toronto, et la chose la plus utile que je puisse vous donner n'est pas du code. C'est le schéma que je redessinais à chaque appel avec l'équipe :

Les trois décisions qui comptent

WebSockets, pas de polling. Un chauffeur envoie sa position toutes les 2 secondes. En HTTP, c'est une nouvelle connexion, des en-têtes et une authentification à chaque signal. Sur un seul WebSocket, c'est une trame de 30 octets. Avec 200 chauffeurs connectés, ça change tout.

Le serveur ne fait que le matching, rien d'autre. La répartition décide quel chauffeur reçoit la course et relaie les positions. Elle ne porte pas l'appel vocal.

La voix passe de pair à pair. WebRTC a besoin du serveur une seule fois, pour la poignée de main (des messages du même type que les flèches 1 et 2, pour échanger les adresses réseau). Ensuite, l'audio circule de téléphone à téléphone. Coût réseau nul de votre côté, latence plus basse pour eux.

La pile pour les curieux : Laravel pour l'API et le matching, WebSockets pour le canal en direct, WebRTC pour les appels, et une file d'attente (voir le premier article) pour les reçus et les notifications.