System-Design-Interview: Entwerfe Uber
„Entwerfe Uber" ist eine der häufigsten System-Design-Aufgaben, weil sie geografische Indizierung, Echtzeit-Standortstreaming, Matching und hohen Schreibdurchsatz gleichzeitig berührt. Der Interviewer sucht nicht die echte Uber-Architektur — er will sehen, wie du das Problem eingrenzt, vertretbare Entscheidungen triffst und laut über die Skalierung nachdenkst.
Arbeite es in bewusster Reihenfolge durch: Anforderungen klären, Skalierung abschätzen, die Kernentitäten und APIs skizzieren, Daten und Matching-Pfad entwerfen und dann Engpässe und Trade-offs besprechen. Der folgende Leitfaden folgt dieser Reihenfolge, damit du die Struktur übst, nicht nur die Antwort.
1. Anforderungen klären
Trenne Funktionales von Nicht-Funktionalem und lege den Umfang vor dem Entwurf fest. Fahrgäste fordern eine Fahrt an und sehen den Fahrer in Echtzeit näherkommen; Fahrer gehen online und erhalten Anfragen aus der Nähe; das System ordnet sie zu und verfolgt die Fahrt bis zum Abschluss.
- Funktional: eine Fahrt anfordern, einem nahen Fahrer zuordnen, die Fahrt live verfolgen, Tarifberechnung, Fahrtverlauf.
- Nicht-funktional: latenzarmes Matching (Sekunden), hohe Verfügbarkeit, Echtzeit-Standortaktualisierungen, Konsistenz — ein Fahrer wird genau einem Fahrgast zugeordnet.
- Außerhalb des Umfangs (das offen sagen): interne Zahlungsabwicklung, Bewertungen, Surge-ML — erwähnen und dann zurückstellen.
2. Skalierung abschätzen
Grobe Zahlen rechtfertigen spätere Entscheidungen. Angenommen ~10 Mio. täglich aktive Fahrer senden alle 4 Sekunden ein Standort-Ping — das sind ~2,5 Mio. Schreibvorgänge pro Sekunde an Standortdaten, eine schreiblastige Last, die eine naive relationale Tabelle als Hot Path sofort ausschließt.
3. Kernkomponenten und APIs
Skizziere die Dienste und den Anfragefluss. Halte den Matching-Pfad unabhängig vom dauerhaften Fahrten-Speicher, damit jeder nach seinen eigenen Merkmalen skaliert.
- Standortdienst: nimmt Fahrer-Pings auf und hält aktuelle Positionen in einem In-Memory-Geoindex.
- Matching-Dienst: fragt bei einer Fahrtanfrage nahe Online-Fahrer ab und weist einen zu.
- Fahrtendienst: dauerhafter Datensatz des Fahrtenlebenszyklus (angefordert → zugeordnet → unterwegs → abgeschlossen).
- Benachrichtigung/Streaming: sendet die Live-Position des Fahrers an den Fahrgast (WebSocket/Long-Poll).
4. Geografisches Matching — der Kern des Problems
Das will der Interviewer am meisten hören. Rohe Lat/Long zu speichern und zu durchsuchen ist O(n); du brauchst einen räumlichen Index. Erkläre Quadtrees oder Geohashing: die Karte in Zellen unterteilen, sodass „Fahrer in der Nähe dieses Punkts finden" zu einer Abfrage von wenigen Zellen wird statt eines vollständigen Scans.
Geohashing kodiert eine Region in eine kurze Zeichenfolge, bei der gemeinsame Präfixe räumliche Nähe bedeuten, was „in der Nähe" zu einer Präfixabfrage macht. Die aktuellen Zellen der Fahrer liegen in einem In-Memory-Speicher (z. B. Redis) für schnelle Lesevorgänge und häufige Updates; die Zellgröße ist ein einstellbarer Trade-off zwischen Präzision und Abfragestreuung.
5. Skalierung und Engpässe
Nenne die Druckpunkte und wie du sie entlasten würdest. Der Strom von 2,5 Mio. Standort-Schreibvorgängen pro Sekunde ist der dominierende.
- Den Standortindex geografisch sharden — Fahrer und Fahrgäste einer Stadt werden vom selben Shard bedient, wodurch das Matching lokal bleibt.
- Die Schreibspitze mit einem In-Memory-Speicher und asynchronen dauerhaften Schreibvorgängen abfangen; nicht jedes Ping muss in einer dauerhaften DB landen.
- Ein Fahrer pro Fahrgast mit einer atomaren Zuordnung (Lock oder bedingtes Update) sicherstellen, um Doppelbuchungen zu vermeiden.
- Eine Message-Queue (Kafka) zwischen Standort-Ingestion und nachgeschalteten Konsumenten nutzen, um Spitzen zu entkoppeln.
6. Trade-offs, die man ansprechen sollte
Schließe ab, indem du die Spannungen nennst, die ein Interviewer honoriert: starke vs. eventuelle Konsistenz (die Fahrerzuordnung muss stark sein; die Standortanzeige darf eventuell sein), In-Memory-Geschwindigkeit vs. Dauerhaftigkeit, und Zellgrößen-Präzision vs. Abfragestreuung. Das explizit zu benennen, ist der Unterschied zwischen einer bestandenen und einer starken Antwort.
Übe Ubers Systemdesign mit Echtzeit-Hilfe
Der System-Design-Interview-Assistent von Natively kann dich während einer Live-Runde strukturiert halten — er schlägt die nächste zu behandelnde Dimension vor und zeigt Trade-offs in Echtzeit, alles auf deinem eigenen Gerät.
