Hvad betyder skalerbarhed ved udvikling af en app?

Nogle gange kommer øjeblikket listende: Appen føles "lidt" langsommere, supportbilletterne hober sig op, og release-dagene bliver nervøse.

Og nogle gange kommer det som et brag. En kampagne bryder igennem, en presseomtale skaber en top, eller dit Purpose-projekt bliver delt i et nyhedsbrev. Fra 500 daglige brugere til 50.000 – ikke over et år, men over en weekend.

I vores projekter ser vi: Skalerbarhed bliver sjældent vigtig på grund af kærlighed til teknologi, men snarere på grund af tillidskærlighed. Hvis en app vakler under belastning, sker der ikke bare "en fejl". Der sker noget i hovedet på folk: Brugere falder fra, anmeldelser ændrer sig, og teams går i krisetilstand.

Den forventning er ærlig. Selv ved mobile weboplevelser viser det sig, hvor lidt tålmodighed der er: Over 53 procent forlader en side, hvis den tager mere end tre sekunder at indlæse. Marketing Dive (Google-undersøgelse, 2016)

Selvom apps ikke er en til en med websites – er den følelsesmæssige logik den samme: "Hvis det ikke virker med det samme, er det ikke pålideligt."

Vores første friske perspektiv: Skalerbarhed er også effektsikkerhed. Hvis du bygger en uddannelsesapp, der skal nå flere mennesker, eller en platform, der sætter donationer i gang, er stabilitet ikke bare et teknisk problem. Det er en del af dit ansvar: Din mission må ikke fejle ved et overbelastet login-endepunkt.

Derfor starter vi tidligt hos Pola med et enkelt, men afgørende spørgsmål: Hvad skal din app være forberedt på – planbar vækst, upredikerbare toppe eller begge dele? Denne skelnen afgør senere, om du primært prioriterer kapacitet, elasticitet eller robusthed.

Når nogen siger "Vi skal bygge appen skalerbar", mener de ofte kun: "Flere brugere skal kunne komme ind på samme tid." Det er vigtigt – men det er kun halvdelen af historien.

Skalerbarhed har to vækstakser:

For det første: Belastningsvækst. Flere samtidige forespørgsler, mere datatrafik, flere enheder, flere sidejobs i dit system (push, synkronisering, uploads). App-markedet vokser stadig, og med det forventningen om, at alt bare virker. Den rene tæthed viser presset: I 2023 var der over 3,7 millioner apps i Google Play Store og omkring 1,8 millioner i Apple App Store. Selleo

For det andet: Funktionalitetens vækst. Nye funktioner, nye roller, nye integrationer, nye markeder. En app, der startede med 5 skærme, bliver med tiden et produkt med regler, særlige tilfælde og undtagelser. Og lige her falder mange ting: Ikke fordi CPU'en er for svag, men fordi hver ændring pludselig bliver risikabel.

Vigtigt er sondringen: Skalerbarhed er ikke det samme som ydeevne. Ydeevne beskriver, hvor hurtigt noget er ved en bestemt belastning. Skalerbarhed beskriver, hvor godt appen holder sin ydeevne, når belastningen stiger.

En analogi fra hverdagen, vi godt kan lide: Ydeevne er, hvor hurtigt et tog kører på åben strækning. Skalerbarhed er, om planen stadig holder, når tre gange så mange mennesker pludselig stiger ombord – uden at dørene klemmer, signaler svigter eller hele driften stopper.

Vores andet friske perspektiv: Skalerbarhed er team-venlig arkitektur. I praksis vokser ikke kun appen, men også det team, der arbejder på den. Hvis flere udviklere skal levere parallelt, har du brug for strukturer, der afkobler ændringer fra hinanden. En "skalerbar app" betyder derfor også: let testbar, modulær, forståelig.

Hvis du kalder disse to akser tidligt, bliver beslutninger lettere: Nogle projekter har brug for belastningsreservationer først, andre har først en ren base for funktionsvækst. Og ofte er det en blanding – men med en klar vægtning.

Når apps "går i stykker" under belastning, ligner det udefra ofte et enkelt problem: "Server overbelastet." I virkeligheden er det næsten altid en kæde af flaskehalse.

En klassiker er databasen. I begyndelsen er den bekvem: en central placering, alt konsistent, alt sporbar. Og så kommer øjeblikket, hvor en enkelt forespørgsel pludselig kører tusind gange oftere. Eller en lås blokerer skriveadgang. Eller et dårligt valgt indeks gør en søgning til en tekstrejse.

Ligeså hyppigt er det koden. Ikke "for langsomt programmeret", men for tæt koblet. En funktion kalder tre andre, venter på en ekstern API og skriver synkront logs. Det fungerer med 50 brugere. Med 5.000 bliver det til en dominoeffekt.

Derefter er der den flaskehals, som næsten ingen taler om først: Processer og udgivelser. Hvis en hotfix kun kan installeres om natten, hvis deployment er skræmmende, hvis ingen præcis ved, hvad der skal observeres efter udgivelsen – så skalerer ikke systemet, men stressniveauet.

Vores tredje friske perspektiv: Skalerbarhed er incident-venlighed. Vi bygger ikke kun til "mere", vi bygger til "hvis noget går galt". Dette er en stille forskel: En robust app har klare grænser, klare timeouts, klare tilbagetrækningsmuligheder. Og den hjælper teamet med hurtigt at forstå, hvad der sker.

I praksis anvender vi et lille princip, som du nemt kan tage med: "Gør det kritiske kort." Alt, hvad der er dit kritiske øjeblik (registrering, checkout, donation), bør have så få afhængigheder som muligt. Hvis du derefter vil sende mails, generere PDF'er eller opdatere statistikker, gør det asynkront.

Det viser også, hvorfor mange nedbrud er så dyre: Nedetid er ikke kun en teknisk tilstand, men en forretningsmæssig skade. Atlassian nævner eksempler, hvor nedbrud hos store virksomheder har medført skader i tocifret millionbeløb. Atlassian

Du behøver ikke være Facebook for at mærke denne effekt. Mindre produkter har kun færre buffere.

Når vi taler om skalering, ender vi hurtigt ved to grundmodeller: vertikal og horisontal.

Vertikal betyder: Du tilføjer et system mere kraft. Mere CPU, mere RAM, en større databasesætning. Det er ofte det første skridt, da det hurtigt gør en forskel og kræver ringe ombygning. Men vertikal skalering har grænser: det bliver meget dyrt, og du har fortsat et centralt punkt, der kan svigte.

Horisontal betyder: Du spreder belastningen på flere instanser. Ikke én stærkere server, men flere – ideelt set sådan, at du ved toppe kan skalere op automatisk og ned ved stilhed.

For at få horisontal til at fungere har du normalt brug for to ting: en Load Balancer (der fordeler trafikken) og services, der er statsløse. Det lyder teknisk, men er let at forstå: Hvis en bruger-login kun fungerer på server A, fordi sessionen er der, kan server B ikke hjælpe. Hvis tilstanden derimod ligger i en fælles hukommelse (f.eks. i en database eller cache som Redis), kan vilkårlige instanser træde til.

I praksis er skalering ofte en blanding: Lidt vertikalt for at få luft hurtigt og målrettet horisontalt, hvor det virkelig gælder.

Hvad vi altid medtænker: Pålidelighed er en søster til skalerbarhed. Så snart du arbejder horisontalt, opbygger du ofte automatisk redundans. En instans svigter, andre overtager. Det er ikke kun "mere ydeevne", men mindre risiko.

Og her kommer vores Pola-perspektiv ind: Vi kan ikke lide "permanent maksimal ydeevne". Det bliver bæredygtigt, når dit system er elastisk. Ekstra ressourcer kun når de er nødvendige. Det sparer omkostninger og undgår unødvendigt energiforbrug – den tekniske side af en holdning: ikke spilde.

Hvis du står i begyndelsen, er den vigtigste beslutning derfor ikke "Kubernetes eller ej", men: Kan din app grundlæggende klare flere instanser? Hvis du forbereder det ordentligt, har du mange muligheder.

Arkitekturspørgsmålet føres ofte ideologisk: monolit dårligt, microservices godt. Vi ser det anderledes. For mange produkter er en godt bygget monolit i starten det rigtige: hurtigere at implementere, lettere at teste, lettere at forstå.

Problemet er sjældent monolitten selv, men en monolit uden grænser. Når alt kender alt, bliver hver ændring dyr.

Derfor bruger vi gerne en anden praktisk afprøvet metode: "Skær efter ansvar, ikke efter teknologi." Konkret betyder det: Vi strukturerer tidligt efter forretningsområder, så du senere kan løsrive enkelte dele uden at rive hele produktet fra hinanden.

En typisk vej ser således ud:

• Start som en modular monolith med klare domæner (f.eks. konti, indhold, betalinger).
• Når et domæne vokser stærkt eller får særlige krav, bliver det udskilt som en egen service.
• Først når teams og drift virkelig drager fordel af det, opstår der flere selvstændige services.

Hvorfor denne rækkefølge? Fordi microservices godt kan lade dig betjene dele uafhængigt, men de bringer nye opgaver med sig: netværkskommunikation, distribueret debugging, versionsstyring, observability. Det kan betale sig, når kompleksiteten allerede er der – ikke for at "købe" kompleksitet.

Her passer også en vigtig advarsel fra startup-konteksten: Der er indikationer på, at en stor del af startup-fejl skyldes for tidlig skalering – ofte organisatorisk og strategisk, men tanken kan overføres. LinkedIn Post (Startup Genome-tal, bredt delt)

Vores holdning til det: Planlæg døren, byg ikke direkte hele huset. En app må gerne starte som MVP. Men den bør være bygget på en måde, så du ikke skal starte forfra ved hver væksttrin.

Hvis du vil fordybe dig i sådanne beslutninger: Vi har også fulgt lignende arkitekturspørgsmål i app-projekter, hvor der senere kom nye funktioner og brugergrupper til (f.eks. Ureka eller Aeri). Konteksten er hver gang anderledes – princippet forbliver: Klarhed før størrelse.