System design-interview: Ontwerp Uber
"Ontwerp Uber" is een van de meest voorkomende system design-opdrachten omdat het tegelijk geospatiale indexering, realtime locatiestreaming, matching en een hoge schrijfdoorvoer raakt. De interviewer zoekt niet de echte Uber-architectuur — hij wil zien dat je het probleem afbakent, verdedigbare keuzes maakt en luidop redeneert over schaal.
Werk het in een doordachte volgorde uit: verhelder de vereisten, schat de schaal, schets de kernentiteiten en API's, ontwerp de data en het matchingpad, en bespreek dan de knelpunten en trade-offs. De onderstaande gids volgt die volgorde zodat je de structuur oefent, niet alleen het antwoord.
1. Vereisten verhelderen
Scheid functioneel van niet-functioneel en leg de scope vast voordat je ontwerpt. Passagiers vragen een rit aan en zien de chauffeur in realtime naderen; chauffeurs gaan online en ontvangen nabije verzoeken; het systeem matcht ze en volgt de rit tot aan afronding.
- Functioneel: een rit aanvragen, matchen met een nabije chauffeur, de rit live volgen, tariefberekening, ritgeschiedenis.
- Niet-functioneel: matching met lage latentie (seconden), hoge beschikbaarheid, realtime locatie-updates, consistentie — een chauffeur wordt aan precies één passagier toegewezen.
- Buiten scope (zeg dit expliciet): de interne verwerking van betalingen, beoordelingen, surge-ML — noem ze en stel ze dan uit.
2. Schaal inschatten
Globale cijfers rechtvaardigen latere keuzes. Neem aan dat ~10 miljoen dagelijks actieve chauffeurs elke 4 seconden een locatieping versturen — dat is ~2,5 miljoen schrijfacties per seconde aan locatiegegevens, een schrijfzware belasting die een naïeve relationele tabel als hot path onmiddellijk uitsluit.
3. Kerncomponenten en API's
Schets de services en de requestflow. Houd het matchingpad onafhankelijk van de duurzame ritopslag, zodat elk op zijn eigen kenmerken kan schalen.
- Locatieservice: neemt chauffeurspings op en houdt actuele posities bij in een geospatiale index in het geheugen.
- Matchingservice: zoekt bij een ritverzoek naar nabije online chauffeurs en wijst er een toe.
- Ritservice: duurzame registratie van de ritlevenscyclus (aangevraagd → gematcht → onderweg → afgerond).
- Melding/streaming: stuurt de live positie van de chauffeur naar de passagier (WebSocket/long-poll).
4. Geospatiale matching — de kern van het probleem
Dit wil de interviewer het liefst horen. Ruwe lat/long opslaan en doorzoeken is O(n); je hebt een ruimtelijke index nodig. Leg quadtrees of geohashing uit: deel de kaart op in cellen zodat 'vind chauffeurs nabij dit punt' een opzoeking van een paar cellen wordt in plaats van een volledige scan.
Geohashing codeert een regio in een korte string waarbij gedeelde voorvoegsels ruimtelijke nabijheid betekenen, waardoor 'nabij' een prefixquery wordt. De huidige cellen van chauffeurs staan in een opslag in het geheugen (bijv. Redis) voor snelle leesacties en frequente updates; celgrootte is een instelbare trade-off tussen precisie en query-fan-out.
5. Schaalbaarheid en knelpunten
Benoem de drukpunten en hoe je ze zou verlichten. De stroom van 2,5 miljoen locatieschrijfacties per seconde is de dominante.
- Shard de locatie-index geografisch — chauffeurs en passagiers van een stad worden door dezelfde shard afgehandeld, zodat matching lokaal blijft.
- Vang de schrijfpiek op met een opslag in het geheugen en asynchrone duurzame schrijfacties; niet elke ping moet in een duurzame database terechtkomen.
- Garandeer één chauffeur per passagier met een atomaire toewijzing (een lock of voorwaardelijke update) om dubbele boekingen te voorkomen.
- Gebruik een message queue (Kafka) tussen locatie-ingestie en downstream consumenten om pieken te ontkoppelen.
6. Trade-offs om te benoemen
Sluit af door de spanningen te benoemen die een interviewer waardeert: sterke versus eventuele consistentie (chauffeurstoewijzing moet sterk zijn; locatieweergave mag eventueel zijn), snelheid in het geheugen versus duurzaamheid, en precisie van celgrootte versus query-fan-out. Dit expliciet benoemen is het verschil tussen een voldoende en een sterk antwoord.
Oefen het systeemontwerp van Uber met realtime hulp
De system design-interviewassistent van Natively kan je gestructureerd houden tijdens een live ronde — door de volgende dimensie te suggereren en trade-offs in realtime te laten zien, allemaal op je eigen apparaat.
