Hva betyr skalerbarhet ved utvikling av en app?

Vekst avdekker svakheter som tidligere var usynlige

Noen ganger kommer øyeblikket gradvis: Appen føles «litt» tregere, supporthenvendelsene hoper seg opp, og lanseringsdagene blir nervøse.

Og noen ganger kommer det som et smell. En kampanje slår an, en omtale i pressen skaper en topp, eller prosjektet ditt med et formål blir delt i et nyhetsbrev. 500 daglige brukere blir til 50.000 – ikke over et år, men i løpet av en helg.

I prosjektene våre ser vi: Skalerbarhet blir sjelden viktig på grunn av kjærlighet til teknologi, men på grunn av kjærlighet til tillit. For når en app vakler under belastning, skjer det ikke bare «en feil». Det skjer noe i hodene til folk: Mennesker gir opp, vurderingene faller, og team går inn i krisemodus.

For forventningene er brutalt ærlige. Allerede ved mobile nettopplevelser ser man hvor lite tålmodighet folk har: Over 53 prosent forlater en side hvis den laster i mer enn tre sekunder. Marketing Dive (Google-Studie, 2016)↗

Selv om apper ikke er det samme som nettsteder – den emosjonelle logikken er den samme: «Hvis det ikke fungerer med en gang, er det ikke pålitelig.»

Vårt første friske perspektiv: Skalerbarhet er også sikkerhet for effekt. Hvis du bygger en læringsapp som skal nå flere mennesker, eller en plattform som setter donasjoner i bevegelse, er stabilitet ikke bare et teknisk tema. Det er en del av ansvaret ditt: Oppdraget ditt må ikke mislykkes på grunn av et overbelastet innloggingsendepunkt.

Derfor starter vi tidlig hos Pola med et enkelt, men avgjørende spørsmål: Hva må appen din være forberedt på – forutsigbar vekst, uforutsigbare topper eller begge deler? Dette skillet avgjør senere om du først og fremst prioriterer kapasitet, elastisitet eller robusthet.

Brukerbelastning og produktkompleksitet vokser uavhengig av hverandre

Når noen sier «Vi må bygge appen skalerbar», mener han eller hun ofte bare: «Flere brukere skal kunne være inne samtidig.» Det er viktig – men det er bare halve historien.

Skalerbarhet har to vekstakser:

For det første: Belastningsvekst. Flere samtidige forespørsler, mer datatrafikk, flere enheter, flere bakgrunnsjobber i systemet ditt (push, synkronisering, opplastinger). Appmarkedet fortsetter å vokse, og med det forventningen om at alt bare fungerer. Bare den enorme tettheten viser presset: I 2023 var det over 3,7 millioner apper i Google Play Store og rundt 1,8 millioner i Apple App Store. Selleo↗

For det andre: Funksjonsvekst. Nye funksjoner, nye roller, nye integrasjoner, nye markeder. En app som startet med 5 skjermer, blir over tid et produkt med regler, spesialtilfeller og unntak. Og det er nettopp her mye tipper over: Ikke fordi CPU-en er for svak, men fordi hver endring plutselig blir risikabel.

Det er viktig å skille mellom: Skalerbarhet er ikke det samme som ytelse. Ytelse beskriver hvor raskt noe er ved en bestemt belastning. Skalerbarhet beskriver hvor godt appen opprettholder ytelsen når belastningen øker.

Et bilde fra hverdagen som vi gjerne bruker: Ytelse er hvor raskt et tog kjører når sporet er fritt. Skalerbarhet er om rutetabellen fortsatt holder når plutselig tre ganger så mange mennesker går om bord – uten at dører setter seg fast, signaler svikter eller hele driften stopper opp.

Vårt andre friske perspektiv: Skalerbarhet er teamvennlig arkitektur. I praksis vokser ikke bare appen, men også teamet som jobber med den. Når flere utviklere skal levere parallelt, trenger du strukturer som kobler endringer fra hverandre. En «skalerbar app» betyr derfor også: lett å teste, modulær, forståelig.

Hvis du navngir disse to aksene tidlig, blir beslutninger enklere: Noen prosjekter trenger først belastningsreserver, andre først et ryddig grunnlag for funksjonsvekst. Og ofte er det en blanding – men med en tydelig prioritering.

Fire spørsmål gjør reserver konkrete

Skalerbarhet blir raskt en magefølelse når ingen fastsetter hva som kjennetegner «nok». Derfor prøver vi å gi temaet en form tidlig som fungerer i hverdagen.

Metoden vår, utprøvd i praksis, kaller vi internt Fire-spørsmålstesten. Den er bevisst enkel, slik at den ikke forsvinner i prosjektet:

1) Hva er ditt kritiske øyeblikk? For eksempel: registrering, utsjekking, fullføring av donasjon, dataopplasting.

2) Hva betyr «kritisk» i tall? For eksempel: 500 samtidige økter eller 50 forespørsler per sekund – med et mål for svartider.

3) Hva får det koste? Ikke bare monetært, men også som driftskompleksitet.

4) Hva skjer hvis det går galt? Tap av omsetning, tap av tillit, tapt effekt.

Dermed kommer vi til måltall du kan følge med på uten å drukne i tall: Latenstid (responstid, gjerne som 95. persentil), Gjennomstrømning (forespørsler per sekund), Feilrate (time-outs, 5xx, krasjrater) og Kostnad per forespørsel.

Hvorfor også kostnader? Fordi skalering ellers blir dyrt i det skjulte. God skalerbarhet betyr ikke «alltid flere servere», men mer ytelse per ressurs som tas i bruk. Nettopp her ligger en ofte oversett ROI: En mer effektiv app sparer skykostnader og reduserer samtidig energiforbruket.

For den økonomiske siden hjelper en realitetssjekk: Selv små forsinkelser kan bli dyre. Amazon har internt observert at 100 millisekunder ekstra forsinkelse kan påvirke omsetningen med 1 prosent. LinkedIn Post (Amazon-Zitat, weiterverbreitet)↗

Vi bruker ikke slike tall for å skape press, men for å tydeliggjøre prioriteten: Hvis det kritiske øyeblikket ditt er konverteringen, er skalerbarhet ikke et «tech-ekstra», men beskyttelse av verdiskapingen din.

Og enda en ting som utgjør forskjellen i praksis: Målbarhet er også beroligende. Når du har overvåking og lasttester, trenger du ikke å håpe. Du kan vite.

En topp treffer alltid den trangeste delen

Når apper går i stykker «under belastning», ser det utenfra ofte ut som ett enkelt problem: «Serveren er overbelastet.» I virkeligheten er det nesten alltid en kjede av flaskehalser.

Helt klassisk er databasen. I begynnelsen er den praktisk: ett sentralt sted, alt konsistent, alt etterprøvbart. Og så kommer øyeblikket der én enkelt spørring plutselig kjøres tusen ganger oftere. Eller en lås blokkerer skrivetilgang. Eller en dårlig valgt indeks gjør et søk til en fulltekst-vandring.

Minst like ofte er det koden. Ikke «programmert for tregt», men for tett koblet. En funksjon kaller tre andre, venter på et eksternt API og skriver samtidig logger synkront. Det fungerer med 50 brukere. Med 5.000 blir det en dominoeffekt.

Og så finnes det flaskehalsen som nesten ingen snakker om først: Prosesser og releaser. Hvis en hotfix bare kan legges inn om natten, hvis deployments skaper frykt, hvis ingen vet nøyaktig hva som må overvåkes etter releasen – da er det ikke systemet som skalerer, men stressnivået.

Vårt tredje friske perspektiv: Skalerbarhet er hendelsesvennlighet. Vi bygger ikke bare for «mer», vi bygger for «når noe går galt». Det er en stille forskjell: En robust app har klare grenser, klare timeouts, klare fallbacks. Og den hjelper teamet med å raskt forstå hva som skjer.

I praksis liker vi å bruke et lite prinsipp til dette, som du kan ta med deg med en gang: «Gjør det kritiske kort.» Alt som er ditt kritiske øyeblikk (registrering, checkout, donasjon), bør ha så få avhengigheter som mulig. Hvis du etterpå fortsatt vil sende e-poster, generere PDF-er eller oppdatere statistikk, gjør det asynkront.

Her ser man også hvorfor mange driftsavbrudd er så kostbare: Nedetid er ikke bare en teknisk tilstand, men en forretningsskade. Atlassian nevner eksempler der driftsavbrudd hos store selskaper har forårsaket skader på tosifret millionnivå. Atlassian↗

Du trenger ikke å være Facebook for å merke denne effekten. Mindre produkter har bare mindre buffer.

Mer kraft og flere instanser løser ulike problemer

Når vi snakker om skalering, ender vi raskt opp med to grunnmodeller: vertikal og horisontal.

Vertikalt betyr: Du gir et system mer kraft. Mer CPU, mer RAM, et større databaseoppsett. Dette er ofte det første steget, fordi det virker raskt og krever lite ombygging. Men vertikal skalering har grenser: på et tidspunkt blir det svært dyrt, og du har fortsatt et sentralt punkt som kan svikte.

Horisontalt betyr: Du fordeler belastningen på flere instanser. Ikke én kraftigere server, men flere – ideelt sett slik at du automatisk kan skalere opp ved topper og skalere ned igjen i rolige perioder.

For at horisontal skalering skal fungere, trenger du som regel to ting: en Load Balancer (som fordeler trafikken) og tjenester som er tilstandsfattige . Det høres teknisk ut, men er lett å forstå: Hvis en brukerinnlogging bare fungerer på server A, fordi sesjonen ligger der, kan ikke server B hjelpe. Hvis tilstanden derimot ligger i et felles lager (f. eks. i en database eller en cache som Redis), kan vilkårlige instanser ta over.

I praksis er skalering ofte en blanding: Litt vertikalt, for å få litt luft raskt, og målrettet horisontalt der det virkelig teller.

Det vi alltid tenker på samtidig: Pålitelighet er et søsken til skalerbarhet. Sobald du horizontal arbeitest, baust du häufig automatisch Redundanz ein. Fällt eine Instanz aus, übernehmen andere. Das ist nicht nur „mehr Leistung“, sondern weniger Risiko.

Und hier kommt unsere Pola-Perspektive rein: Wir mögen keine „Dauer-Maximalleistung“. Nachhaltig wird es, wenn dein System elastisch ist. Zusätzliche Ressourcen nur dann, wenn sie gebraucht werden. Das spart Kosten und vermeidet unnötigen Energieverbrauch – die technische Seite einer Haltung: nicht verschwenden.

Wenn du gerade am Anfang stehst, ist die wichtigste Entscheidung deshalb nicht „Kubernetes oder nicht“, sondern: Kann deine App grundsätzlich mehrere Instanzen vertragen? Wenn du das sauber vorbereitest, bleiben dir viele Wege offen.

Der einfachste tragfähige Pfad ist oft der beste

Die Architekturfrage wird oft unnötig ideologisch geführt: Monolith schlecht, Microservices gut. Wir sehen das anders. Für viele Produkte ist ein gut gebauter Monolith am Anfang genau richtig: schneller umzusetzen, leichter zu testen, leichter zu verstehen.

Das Problem ist selten der Monolith an sich, sondern ein Monolith ohne Grenzen. Wenn alles alles kennt, wird jede Änderung teuer.

Darum nutzen wir gern eine zweite praxiserprobte Methode: „Schneide nach Verantwortung, nicht nach Technik.“ Konkret heißt das: Wir strukturieren früh nach fachlichen Bereichen, sodass du später einzelne Teile herauslösen kannst, ohne das ganze Produkt auseinanderzureißen.

Ein typischer Pfad sieht so aus:

• Start als modularer Monolith mit klaren Domänen (z. B. Accounts, Inhalte, Zahlungen).
• Wenn eine Domäne stark wächst oder besondere Anforderungen bekommt, wird sie als eigener Service ausgelagert.
• Erst wenn Teams und Betrieb wirklich davon profitieren, entstehen mehrere eigenständige Services.

Warum diese Reihenfolge? Weil Microservices dir zwar erlauben, Teile unabhängig zu betreiben, aber sie bringen neue Aufgaben mit: Netzwerkkommunikation, verteiltes Debugging, Versionierung, Observability. Das lohnt sich, wenn Komplexität ohnehin da ist – nicht, um Komplexität zu „kaufen“.

Hier passt auch eine wichtige Warnung aus dem Startup-Kontext: Es gibt Hinweise, dass ein großer Teil von Startup-Fehlschlägen mit zu frühem Skalieren zusammenhängt – oft organisatorisch und strategisch, aber der Gedanke ist übertragbar. LinkedIn Post (Startup Genome Zahl, weiterverbreitet)↗

Unsere Haltung dazu: Plane die Tür, bau nicht gleich das ganze Haus. Eine App darf als MVP starten. Aber sie sollte so gebaut sein, dass du nicht bei jedem Wachstumsschritt neu anfangen musst.

Wenn du tiefer in solche Entscheidungen einsteigen willst: Wir haben ähnliche Architekturfragen auch in App-Projekten begleitet, etwa dort, wo später neue Funktionen und Nutzergruppen dazu kamen (z. B. Ureka oder Aeri). Kontexten er forskjellig hver gang – prinsippet forblir: Klarhet før størrelse.

Caching og frakobling skaper målrettede reserver

Når vi forbedrer skalerbare apper pragmatisk, starter vi sjelden med «store» ombygginger. Som regel gir noen få målrettede byggeklosser umiddelbart stabilitet – og de passer også til en bærekraftig tankegang, fordi de reduserer sløsing med ressurser.

Caching er ofte det første. Hvis 10.000 mennesker åpner den samme startsiden, bør systemet ditt ikke gjøre det samme arbeidet 10.000 ganger. En cache (for eksempel Redis) lagrer ofte brukte data i minnet og avlaster database og backend.

CDN-er er den andre klassikeren. Bilder, ressurser, noen ganger til og med deler av API-svar kan leveres nærmere brukeren. Det reduserer latenstid og belastningen på kjernesystemet. For mange team er Cloudflare en rask inngang, fordi du kan kombinere CDN, caching og beskyttelsesfunksjoner på en god måte.

Køer er vår favorittbyggekloss når topper er uforutsigbare. I stedet for å ville gjøre alt med én gang, tar du imot oppgaver og behandler dem i bakgrunnen. Det jevner ut belastningstopper og gjør systemet ditt «mer tålmodig». Teknisk kan dette gjøres med RabbitMQ eller – i større skala – med Apache Kafka .

Og så har vi databasestrategier: Replikering for bedre lesehastighet, gode indekser, noen ganger partisjonering. Dette er mindre glamorøst enn mikrotjenester, men ofte punktet der det virkelig skjer noe.

Rekkefølgen er ikke noe dogme, snarere en observasjon: Gjør først det åpenbare effektivt, og fordel deretter.

Vårt friske perspektiv på dette: Grønn vekst er ofte ganske enkelt god engineering. En arkitektur som bare skalerer opp ved behov, er som regel rimeligere – og den bruker mindre energi enn et system som permanent kjører på maksimal størrelse. Scand beskriver også skalerbarhet som ressurseffektivitet: Ressurser kobles bare inn når belastningen øker. Scand↗

Hvis du jobber formålsdrevet, er dette et stille, men viktig poeng: Produktet ditt kan vokse uten at driften din «vokser med» som et konstant inferno.

Uten tester forblir robusthet bare en antakelse

Skalerbarhet oppstår ikke bare under byggingen, men fremfor alt under driften. Vi har sett for ofte at team «egentlig» var godt rigget – og så manglet akkurat det som ville gjort toppen håndterbar: en test, en alarm, en tydelig rutine.

Lasttester høres ut som luksus. I virkeligheten er de ofte den billigste realitetssjekken du kan få. Miquido oppsummerer det pragmatisk: Om en app kan vokse, viser seg først gjennom load- og ytelsestester. Miquido↗

Hvis du ser etter et verktøy som passer godt inn i moderne pipelines, liker vi k6 veldig godt: Skriptbasert, godt automatiserbart, tydelig output. For mer klassiske oppsett er JMeter oder Gatling også solide.

Overvåking er den andre delen av ligningen. Ikke bare «CPU er høy», men: Hvilke endepunkter blir trege? Hvilke DB-spørringer dominerer? Hvor øker feilratene? Til dette trenger du observability – metrikker, logger og (i distribuerte systemer) traces. En velprøvd open source-duo er Prometheus pluss Grafana. Hvis du vil komme raskere i gang, er verktøy som Datadog eller New Relic ofte pragmatiske.

Og så kommer incident readiness: Hva skjer når det virkelig brenner?

Vi liker å holde det enkelt og øver inn tre ting med team:

1) En release trenger overvåking. Hvilke metrikker sjekker vi de første 30 minuttene?

2) Alarmer må være handlingsrettede. Heller noen få som stemmer, enn mange som blir ignorert.

3) Rollback er en feature. Hvis det er vanskelig å rulle tilbake, blir hver oppdatering risikabel.

Hva dette har med Pola å gjøre: Arbeidet vårt slutter ikke ved lansering. Vi tenker ytelse, vedlikeholdbarhet og drift sammen – fordi skalerbarhet først er reell når den gir ro i hverdagen. Og ro er til syvende og sist en kvalitetsfaktor som brukerne merker, uten å kunne sette ord på den.