Het framework in vijf fasen (voor een ronde van 45 minuten)
- Requirements – 5 minuten. Scheid functionele eisen (“een URL inkorten, doorverwijzen, eigen aliassen?”) van niet-functionele eisen (schaal, latencydoelen, beschikbaarheid vs. consistentie, duurzaamheid van data). Vraag om getallen: gebruikers, reads vs. writes, hoeveelheid data. Spreek daarna je afbakening hardop uit: “Ik ontwerp voor 100 miljoen DAU, read-heavy in een verhouding van 100:1, redirects onder de 100 ms, en ik laat analytics weg tenzij we tijd overhouden.” Hardop afbakenen is de zet met het sterkste signaal in de hele ronde.
- Schatting – 5 minuten. QPS, opslag en bandbreedte op de achterkant van een bierviltje. Rond af op machten van tien, benoem je aannames en doe een sanity check (“500 miljoen nieuwe URL's per maand ≈ 200 writes per seconde, bescheiden; reads in een verhouding van 100:1 ≈ 20.000 per seconde, en dat bepaalt het ontwerp”). Het gaat niet om precisie; het gaat erom dat je laat zien dat getallen je architectuurkeuzes sturen.
- Ontwerp op hoofdlijnen – 10 minuten. Blokken en pijlen voor het happy path: clients, load balancer, een stateless applicatielaag, datastores, cache, queue. Loop één request hardop van begin tot eind door. Houd het saai: originaliteit levert hier risico op en geen beloning.
- Verdieping – 20 minuten. De interviewer kiest een onderdeel (“hoe voorkomt de ID-generatie precies botsingen?”, “wat gebeurt er als een cache-node uitvalt?”). Hier scheiden de niveaus zich. Word concreet: het datamodel, de keuze van de partition key, de manieren waarop het kan falen en wat de on-call engineer om 3 uur 's nachts wakker belt.
- Afronding – 5 minuten. De bottlenecks die je hierna zou aanpakken, wat je zou monitoren en wat je bewust hebt overgeslagen. Eindigen met bekende beperkingen komt over als senioriteit, niet als zwakte.
Het trade-off-vocabulaire dat senioriteit verraadt
Interviewers letten erop of je uit jezelf naar deze assen grijpt:
| As | De zin die scoort |
|---|---|
| Consistentie vs. beschikbaarheid | “Bij het aantal volgers accepteer ik verouderde data; bij het betalingsgrootboek niet. Andere stores voor andere garanties.” |
| Latency vs. kosten | “Als ik de top 1% van de keys cache, bedien ik ~90% van de reads; alles cachen verdrievoudigt het geheugen voor een marginaal hogere hit rate.” |
| Push vs. pull | “Fan-out-on-write voor gewone gebruikers, fan-out-on-read voor accounts van beroemdheden: hybride, afhankelijk van het aantal volgers.” |
| SQL vs. NoSQL | “Het toegangspatroon is key-value op korte code, zonder joins. Dat maakt een wide-column store hier verdedigbaar, niet de mode.” |
| Sync vs. async | “De gebruiker moet een bevestiging van de write krijgen; de fan-out van notificaties kan via een queue lopen en later worden afgeleverd.” |
De metaregel: noem nooit een technologie zonder de eigenschap erbij te noemen die de keuze rechtvaardigt. “Kafka” is een woord; “een gepartitioneerd log, zodat consumers na een storing opnieuw kunnen afspelen” is een reden.
De tien meest gestelde vragen in een system design interview, met de kern van elke vraag
- URL shortener. Kern: ID-generatie (teller + base62 vs. hash + afhandeling van botsingen) en caching op het leespad. Klassieke opwarmer; reken op vervolgvragen over analytics en verlooptijden.
- Chatsysteem (WhatsApp/Slack). Kern: verbindingsbeheer (WebSockets, presence), de volgorde van berichten per gesprek, aflevergaranties en leesbevestigingen, offline synchronisatie.
- Nieuwsfeed (Twitter/Instagram). Kern: de fan-out-strategie en het celebrity-probleem; ranking als aparte service; paginering met cursors, niet met offsets.
- Rate limiter. Kern: de keuze van het algoritme (token bucket vs. sliding window), gedistribueerd tellen (Redis + Lua), fail-open vs. fail-closed, en waar hij zit (in de gateway of per service).
- Bestandsopslag (Dropbox/Drive). Kern: chunking en deduplicatie, het synchronisatieprotocol en het oplossen van conflicten, de scheiding tussen metadata en blobs.
- Videoplatform (YouTube). Kern: de uploadpipeline (transcoderen als asynchrone jobs), de CDN-strategie, adaptive bitrate; de kosten van opslag.
- Ritten matchen (Uber). Kern: geospatiale indexering (geohash/quadtree), het writevolume van locatie-updates, matching als stateful service, surge als prijsfeed.
- Notificatiesysteem. Kern: een abstractie over meerdere kanalen (push/e-mail/sms), voorkeuren en limieten per gebruiker, idempotentie en retries met deduplicatie, priority queues.
- Gedistribueerde cache. Kern: consistent hashing, het eviction-beleid, cache-aside vs. write-through, bescherming tegen een thundering herd (request coalescing, TTL's met jitter).
- Systeem voor metrics en monitoring. Kern: het writevolume van tijdreeksen, downsampling en bewaartermijnen in lagen, de explosie van tag-cardinaliteit, alerts evalueren als streamingberekening.
Oefen er minstens drie van begin tot eind, hardop, op een whiteboard of in een document, in het tempo van 45 minuten. Een ontwerp vertellen en een ontwerp opschrijven zijn verschillende vaardigheden, en het gesprek beoordeelt het vertellen. Met een oefengesprek met een AI-assistent voor sollicitatiegesprekken krijg je feedback op het niveau van het transcript: precies waar je uitleg de draad kwijtraakte. ChadFlow kan tijdens een live ronde ook meekijken met het venster van je diagram en helpen wanneer er een vervolgvraag komt.
Vijf manieren waarop kandidaten in deze ronde onderuitgaan
- De requirements overslaan. Het verkeerde systeem prachtig ontwerpen is de meest gemaakte fout. Dertig seconden afbakenen voorkomt het.
- Schatten voor de show. Wel rekenen, maar de getallen daarna nooit gebruiken. Als je QPS-schatting niets aan je ontwerp verandert, was het een toneelstukje.
- Architectuur van buzzwords. Kafka, Cassandra of Kubernetes laten vallen zonder de onderbouwing op basis van eigenschappen van hierboven.
- Een monoloog houden. De ronde toetst hoe je samenwerkt. Stem af: “zal ik dieper ingaan op de opslaglaag of doorgaan naar de API?”
- Geen verhaal over storingen. Bij elk onderdeel dat je tekent, hoor je een antwoord te hebben op “wat gebeurt er als dit uitvalt?” Bedenk het antwoord voordat je het blok tekent.
Vertel je ontwerp alsof je het vaker hebt gedaan.
ChadFlow transcribeert je oefenrondes voor system design, coacht je tussen de sessies op je uitleg en helpt live door alleen mee te kijken met het venster van je diagram. Onzichtbaar bij scherm delen.
Download ChadFlow