System design: Bygg systemer som skalerer til millioner av brukere

Hva er system design og hvorfor lære det?

System design er kunsten og vitenskapen å designe store, distribuerte programvaresystemer. Det handler om å ta høynivå krav – "lag en tjeneste som Vipps" eller "design et nyhetsstrøm-system" – og bryte dem ned til konkrete arkitekturvalg: databaser, APIer, caching-strategi, skaleringsmodell og mye mer.

For norske utviklere som sikter mot senior-, arkitekt- eller lederstillinger er system design-kunnskap essensielt. Det er et av de viktigste temaene i tekniske intervjuer hos ledende norske teknologiselskaper, og det er kunnskap som direkte påvirker kvaliteten på systemene du bygger og vedlikeholder.

Skalerbarhet: Horisontal vs vertikal

Skalerbarhet handler om systemets evne til å håndtere vekst i brukere, data og trafikk. Det finnes to grunnleggende tilnærminger: vertikal skalering (scale up) innebærer å gi én maskin mer CPU, RAM og disk. Horisontal skalering (scale out) innebærer å legge til flere maskiner og distribuere arbeidsmengden mellom dem.

Vertikal skalering er enklere å implementere men har et tak (den kraftigste serveren er endelig) og en single point of failure. Horisontal skalering er ubegrenset i teorien og gir redundans, men krever at systemet er designet for distribusjon. De fleste moderne, store norske systemer bruker horisontal skalering som primærstrategien.

• Vertikal skalering: Enkel, men begrenset og dyr over tid
• Horisontal skalering: Kompleks, men ubegrenset og kostnadseffektiv
• Stateless tjenester: Lett å skalere horisontalt – ingen sesjonsstate i prosessen
• Stateful tjenester: Krevende å skalere – krever konsensus og synkronisering
• Auto-scaling: Dynamisk justering basert på faktisk trafikk (AWS, Azure, GCP)
• Elastisitet: Skaler opp og ned etter behov

Load balancing: Fordel trafikken

En load balancer fordeler innkommende forespørsler mellom mange serverinstanser. Dette sikrer at ingen enkelt server blir overbelastet, og gir mulighet for null-nedetid-deployment og automatisk failover om en server krasjer.

Algoritmer for lastfordeling inkluderer Round Robin (roter mellom servere), Least Connections (send til serveren med færrest aktive forbindelser), og IP Hash (send alltid samme klient til samme server – nyttig for sticky sessions). For norske e-handelsplattformer og portaler er load balancing et fundament i arkitekturen.

Databaser og caching-strategi

Databasevalg er ett av de viktigste arkitekturbeslutningene. Relasjonelle databaser (PostgreSQL, MySQL) er best for strukturerte data med komplekse relasjoner og transaksjonskrav. NoSQL-databaser (MongoDB, Cassandra, DynamoDB) egner seg for dokumenter, høy skriveytelse og fleksibelt skjema.

Caching er en av de mest effektive mekanismene for å forbedre ytelse og redusere databasebelastning. Redis og Memcached er de vanligste in-memory cache-løsningene. Caching-strategier inkluderer Cache-Aside (applikasjonen leser fra cache, skriver til DB), Write-Through (skriv til cache og DB samtidig) og Read-Through (cache henter fra DB ved cache miss).

CAP-teoremet og distribuerte systemer

CAP-teoremet, formulert av Eric Brewer i 2000, sier at et distribuert system ikke simultant kan garantere alle tre av: Consistency (alle noder ser samme data), Availability (systemet svarer alltid) og Partition Tolerance (systemet fungerer selv om nettverkspartisjoner oppstår). I praksis er partisjoner uunngåelige, så valget er mellom CP (konsistens ofres for tilgjengelighet) og AP (tilgjengelighet ofres for konsistens).

For norske finanssystemer (banker, forsikring) er konsistens typisk kritisk – man kan ikke ha ulike saldo på ulike servere. For norske nyhetsportaler og sosiale plattformer er tilgjengelighet viktigere – litt gammel data er akseptabelt, men systemet må alltid svare.

"CAP-teoremet er ikke bare akademisk teori – det er avgjørende for hva du lover til brukerne dine og hvordan du designer systemet deretter."

Microservices vs monolitt

Microservices-arkitektur deler applikasjonen inn i mange små, uavhengige tjenester som kommuniserer via APIer eller meldingsbrokers. Monolitter er én stor applikasjon der alt er sammenkoblet. Begge tilnærminger har gyldige brukstilfeller.

Microservices gir uavhengig deployment, teknologifrihet og isolert skalerbarhet – men øker operasjonell kompleksitet dramatisk. En monolitt er enklere å utvikle, debugge og deploye i starten. Mange norske selskaper starter med en monolitt og gradvis ekstraherer tjenester der det er klare grenser og skaleringsbehovet er tydelig.

• Monolitt-fordeler: Enkel utvikling, debug og testing, ett deployment
• Microservices-fordeler: Uavhengig skalering, teknologifrihet, isolerte feil
• Kommunikasjon: REST, gRPC, event-driven (Kafka, RabbitMQ)
• Service mesh: Istio, Linkerd for tjeneste-til-tjeneste-sikkerhet
• API Gateway: Enkelt inngangspunkt til alle tjenester
• Utfordringer: Nettverksforsinkelse, distribuerte transaksjoner, observabilitet

System design i norsk kontekst

Store norske teknologiorganisasjoner som Vipps, Schibsted, Vy og Equinor jobber med distribuerte systemer i stor skala. Vipps håndterer millioner av betalingstransaksjoner daglig med strenge krav til konsistens og tilgjengelighet. Schibsted driver nyhetsportaler og annonsetjenester som krever ekstrem skalerbarhet under trafikktopper.

For norske utviklere er system design-kunnskap stadig viktigere etter hvert som norsk næringsliv digitaliseres og skalerer. Ressurser som "System Design Interview" av Alex Xu, Grokking System Design på Educative.io og ByteByteGo-nyhetsbrevet er populære læringsressurser i det norske tech-miljøet.