Entretien de conception système : Concevoir Uber

« Concevoir Uber » est l'une des consignes de conception système les plus courantes car elle touche à l'indexation géospatiale, au streaming de localisation en temps réel, à l'appariement (matching) et à un débit d'écriture élevé, tout à la fois. Le recruteur ne cherche pas la véritable architecture d'Uber — il veut vous voir cadrer le problème, faire des choix défendables et raisonner sur l'échelle à voix haute.

Avancez dans un ordre délibéré : clarifiez les exigences, estimez l'échelle, esquissez les entités et API principales, concevez les données et le chemin d'appariement, puis discutez des goulots d'étranglement et des compromis. Le guide ci-dessous suit cet ordre pour que vous vous entraîniez sur la structure, pas seulement sur la réponse.

1. Clarifier les exigences

Séparez le fonctionnel du non-fonctionnel et fixez le périmètre avant de concevoir. Les passagers demandent une course et voient le chauffeur approcher en temps réel ; les chauffeurs se connectent et reçoivent des demandes proches ; le système les apparie et suit la course jusqu'à son terme.

Fonctionnel : demander une course, apparier avec un chauffeur proche, suivre la course en direct, calculer le tarif, historique des courses.
Non fonctionnel : appariement à faible latence (quelques secondes), haute disponibilité, mises à jour de localisation en temps réel, cohérence — un chauffeur assigné à exactement un passager.
Hors périmètre (dites-le) : le traitement interne des paiements, les évaluations, le ML de tarification dynamique — mentionnez-les, puis différez-les.

2. Estimer l'échelle

Des chiffres approximatifs justifient les choix ultérieurs. Supposons ~10 millions de chauffeurs actifs quotidiens envoyant un ping de localisation toutes les 4 secondes — soit ~2,5 millions d'écritures par seconde de données de localisation, une charge dominée par l'écriture qui écarte d'emblée une table relationnelle naïve comme chemin critique.

3. Composants principaux et API

Esquissez les services et le flux de requêtes. Gardez le chemin d'appariement indépendant du stockage durable des courses afin que chacun puisse évoluer selon ses propres caractéristiques.

Service de localisation : ingère les pings des chauffeurs et conserve les positions actuelles dans un index géospatial en mémoire.
Service d'appariement : lors d'une demande de course, interroge les chauffeurs en ligne proches et en assigne un.
Service de courses : enregistrement durable du cycle de vie de la course (demandée → appariée → en cours → terminée).
Notification/streaming : transmet la position du chauffeur en direct au passager (WebSocket/long-polling).

4. L'appariement géospatial — le cœur du problème

C'est ce que le recruteur veut le plus entendre. Stocker lat/long bruts et parcourir la liste est en O(n) ; il faut un index spatial. Expliquez les quadtrees ou le geohashing : diviser la carte en cellules pour que « trouver les chauffeurs près de ce point » devienne une recherche sur quelques cellules plutôt qu'un balayage complet.

Le geohashing encode une région en une courte chaîne où des préfixes communs signifient une proximité spatiale, ce qui transforme « proche » en une requête par préfixe. Les cellules actuelles des chauffeurs résident dans un stockage en mémoire (par ex. Redis) pour des lectures rapides et des mises à jour fréquentes ; la granularité des cellules est un compromis ajustable entre précision et dispersion des requêtes.

5. Scalabilité et goulots d'étranglement

Nommez les points de pression et comment vous les soulageriez. Le flux de 2,5 millions d'écritures de localisation par seconde est le plus critique.

Partitionnez (shardez) l'index de localisation géographiquement — les chauffeurs et passagers d'une ville sont traités par le même shard, ce qui garde l'appariement local.
Absorbez le pic d'écriture avec un stockage en mémoire et des écritures durables asynchrones ; vous n'avez pas besoin que chaque ping atteigne une base durable.
Garantissez un chauffeur par passager via une assignation atomique (verrou ou mise à jour conditionnelle) pour éviter les doubles réservations.
Utilisez une file de messages (Kafka) entre l'ingestion de localisation et les consommateurs en aval pour découpler les pics.

6. Compromis à verbaliser

Terminez en nommant les tensions qu'un recruteur valorise : cohérence forte vs éventuelle (l'assignation du chauffeur doit être forte ; l'affichage de la position peut être éventuel), vitesse en mémoire vs durabilité, et précision de la taille des cellules vs dispersion des requêtes. Les énoncer explicitement fait la différence entre une réponse qui passe et une réponse solide.

Entraînez-vous à la conception système d'Uber avec une aide en temps réel

L'assistant d'entretien de conception système de Natively peut vous garder structuré pendant un entretien en direct — en suggérant la prochaine dimension à couvrir et en faisant apparaître les compromis en temps réel, tout sur votre propre appareil.