Elke grootschalige applicatie is opgebouwd uit dezelfde fundamentele bouwstenen. Interviewers verwachten niet dat je nieuwe technologie uitvindt - ze willen zien dat je de juiste componenten kunt selecteren en combineren voor een gegeven probleem. Deze les behandelt de toolkit die je in elk design interview nodig hebt.
In de kern volgt het web een simpel model: clients versturen requests, servers verwerken ze, en responses komen terug. Maar moderne systemen voegen lagen toe tussen deze twee eindpunten om scale, betrouwbaarheid en performance te beheren.
Een typische request kan het volgende pad doorlopen: client → CDN → load balancer → API gateway → application server → cache → database. Elke laag lost een specifiek probleem op, en begrijpen wanneer elke laag nodig is, onderscheidt sterke kandidaten van gemiddelde.
Begin in interviews altijd met het schetsen van de high-level client-server flow voordat je in details duikt. Het toont gestructureerd denken.
Een enkele server heeft beperkte capaciteit. Load balancers verdelen inkomende requests over meerdere servers met strategieën zoals:
Load balancers voeren ook health checks uit en verwijderen automatisch ongezonde servers uit de pool. In cloud-omgevingen handelen services zoals AWS ALB of Azure Front Door dit transparant af.
Een social media feed service ontvangt 10x meer reads dan writes. Welke load balancing aanpak zorgt er het best voor dat gebruikers consistent dezelfde cache-warme server bereiken?
Caching slaat veelgebruikte data op dichter bij de consument. Het bestaat op meerdere niveaus:
| Laag | Voorbeeld | Latency | |------|-----------|---------| | Browser cache | Statische assets, API responses | ~0ms | | CDN | Afbeeldingen, CSS, JS bestanden | ~10-50ms | | Application cache | Redis, Memcached | ~1-5ms | | Database cache | Query result cache | ~5-10ms |
Sign in to join the discussion
Cache invalidation staat bekend als een van de moeilijkste problemen in de informatica. Veelgebruikte strategieën zijn TTL (time-to-live), write-through (cache bijwerken bij elke write) en cache-aside (applicatie beheert de cache expliciet).
Phil Karltons beroemde uitspraak - "Er zijn maar twee moeilijke dingen in Computer Science: cache invalidation en dingen een naam geven" - wordt zo vaak geciteerd dat het praktisch een rite de passage is in system design interviews.
De juiste database kiezen is een van de meest impactvolle designbeslissingen:
SQL databases (PostgreSQL, MySQL) bieden ACID transactions, strong consistency en gestructureerde schemas. Ze excelleren wanneer data duidelijke relaties heeft en je complexe queries met joins nodig hebt.
NoSQL databases komen in verschillende varianten:
Je ontwerpt een systeem dat gebruikersprofielen opslaat met veelveranderende, semi-gestructureerde data (verschillende velden per gebruikerstype). Welk database type past het beste?
Niet elke operatie vereist een onmiddellijk antwoord. Message queues (RabbitMQ, Apache Kafka, AWS SQS) ontkoppelen producers van consumers, wat het volgende mogelijk maakt:
Kafka verdient speciale vermelding: het is niet zomaar een queue maar een distributed event log, dat event-driven architecturen mogelijk maakt waarin meerdere consumers onafhankelijk dezelfde stroom events kunnen verwerken.
| Aspect | Monolith | Microservices | |--------|----------|---------------| | Deployment | Enkele eenheid | Onafhankelijke services | | Scaling | Alles samen schalen | Individuele services schalen | | Complexiteit | Eenvoudiger om te beginnen | Operationele overhead | | Data | Gedeelde database | Database per service |
Begin met een monolith, extraheer microservices wanneer nodig. De meeste interviewers waarderen kandidaten die erkennen dat microservices complexiteit van gedistribueerde systemen met zich meebrengen (netwerkfouten, dataconsistentie, deployment-orchestratie) en niet altijd de juiste keuze zijn.
Netflix migreerde over meerdere jaren van een monolith naar microservices. Maar Shopify - dat miljarden aan transacties verwerkt - draait nog steeds een modulaire monolith. Welke factoren zouden de ene aanpak beter maken dan de andere voor een bepaald bedrijf?
Het CAP theorem stelt dat een gedistribueerd systeem slechts twee van de drie eigenschappen tegelijk kan garanderen:
Aangezien network partitions onvermijdelijk zijn in gedistribueerde systemen, is de echte keuze tussen CP (consistency boven availability) en AP (availability boven consistency).
Je ontwerpt een banktransactiesysteem waarbij onjuiste saldi tot financieel verlies kunnen leiden. Welke CAP-afweging moet je prioriteren?
Volg bij een system design interview deze structuur:
Denk aan een systeem dat je dagelijks gebruikt - Instagram, Uber of Spotify. Kun je identificeren welke bouwstenen uit deze les het waarschijnlijk gebruikt? Waar zou de load balancer zitten? Wat zou gecached worden? Welk database type past bij het datamodel?
Volgende les: we passen deze fundamenten toe om een URL shortener vanaf nul te ontwerpen.