Hvad betyder skalerbarhed ved udvikling af en app?

Vækst afslører svagheder, der tidligere var usynlige

Nogle gange kommer øjeblikket snigende: Appen føles „lidt“ langsommere, supporthenvendelserne hober sig op, og release-dagene bliver nervøse.

Og nogle gange kommer det som et brag. En kampagne slår igennem, en omtale i pressen skaber en peak, eller dit formålsprojekt bliver delt i et nyhedsbrev. Fra 500 daglige brugere bliver det 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 teknik, men på grund af kærlighed til tillid. For når en app vakler under belastning, sker der ikke kun „en fejl“. Der sker noget i folks hoveder: Mennesker falder fra, anmeldelserne vender, teams går i krisemodus.

For forventningerne er brutalt ærlige. Allerede ved mobile weboplevelser viser det sig, hvor lidt tålmodighed der er: Over 53 procent forlader en side, hvis den indlæses i mere end tre sekunder. Marketing Dive (Google-Studie, 2016)↗

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

Vores første friske perspektiv: Skalerbarhed er også sikkerhed for effekt. Hvis du bygger en uddannelsesapp, der skal nå ud til flere mennesker, eller en platform, der sætter donationer i bevægelse, så er stabilitet ikke kun et teknisk emne. Det er en del af dit ansvar: Din mission må ikke fejle på grund af et overbelastet login-endpoint.

Derfor starter vi tidligt hos Pola med et enkelt, men afgørende spørgsmål: Hvad skal din app være forberedt på – på planlagt vækst, på uforudsigelige peaks eller på begge dele? Denne skelnen afgør senere, om du først og fremmest prioriterer kapacitet, elasticitet eller robusthed.

Brugerbelastning og produktkompleksitet vokser uafhængigt af hinanden

Når nogen siger „Vi skal bygge appen skalerbart“, mener han eller hun ofte kun: „Flere brugere skal kunne komme ind samtidig.“ Det er vigtigt – men det er kun den halve historie.

Skalerbarhed har to vækstakser:

For det første: Belastningsvækst. Flere samtidige forespørgsler, mere datatrafik, flere enheder, flere baggrundsopgaver i dit system (push, synkronisering, uploads). Appmarkedet vokser fortsat, og med det forventningen om, at alt bare fungerer. Alene den enorme 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: Funktionsvækst. Nye features, nye roller, nye integrationer, nye markeder. En app, der startede med 5 skærmbilleder, bliver med tiden et produkt med regler, særtilfælde og undtagelser. Og det er præcis her, meget tipper: Ikke fordi CPU'en er for svag, men fordi enhver ændring pludselig bliver risikabel.

Det er vigtigt at skelne: Skalerbarhed er ikke det samme som performance. Performance beskriver, hvor hurtigt noget er ved en bestemt belastning. Skalerbarhed beskriver, hvor godt appen bevarer sin ydeevne, når belastningen stiger.

Et billede fra hverdagen, som vi gerne bruger: Performance er, hvor hurtigt et tog kører på en fri strækning. Skalerbarhed er, om køreplanen stadig holder, når pludselig tre gange så mange mennesker stiger på – uden at dørene sætter sig fast, signalerne svigter eller hele driften går i stå.

Vores anden friske vinkel: Skalerbarhed er teamvenlig arkitektur. I praksis vokser ikke kun appen, men også teamet, 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 at teste, modulær, forståelig.

Hvis du navngiver disse to akser tidligt, bliver beslutninger lettere: Nogle projekter har først brug for belastningsreserver, andre først for et solidt fundament til funktionsvækst. Og ofte er det en blanding – men med en klar prioritering.

Fire spørgsmål gør reserver konkrete

Skalerbarhed bliver hurtigt en mavefornemmelse, hvis ingen fastlægger, hvordan man kan se, at „nok“ er nok. Derfor forsøger vi tidligt at bringe emnet ind i en form, der holder i hverdagen.

Vores gennemprøvede metode kalder vi internt Fire-spørgsmåls-prøven. Den er bevidst simpel, så den ikke forsvinder i projektet:

1) Hvad er dit kritiske øjeblik? For eksempel: registrering, checkout, afslutning af donation, data-upload.

2) Hvad betyder „kritisk“ i tal? For eksempel: 500 samtidige sessioner eller 50 requests i sekundet – med et mål for svartider.

3) Hvad må det koste? Ikke kun monetært, men også som driftskompleksitet.

4) Hvad sker der, hvis det går galt? Tab af omsætning, tab af tillid, mistet impact.

Dermed ender vi ved målepunkter, som du kan overvåge, uden at drukne i tal: Latens (svartid, gerne som 95. percentil), Gennemløb (forespørgsler pr. sekund), Fejlrate (time-outs, 5xx, crash-rater) og Omkostninger pr. forespørgsel.

Hvorfor også omkostninger? Fordi skalering ellers bliver dyr i det skjulte. God skalerbarhed betyder ikke „altid flere servere“, men mere ydelse pr. anvendt ressource. Netop her ligger et ofte overset ROI: En mere effektiv app sparer cloud-omkostninger og reducerer samtidig energiforbruget.

På den økonomiske side hjælper et reality-check: Selv små forsinkelser kan blive dyre. Amazon har internt observeret, at 100 millisekunders ekstra forsinkelse kan påvirke omsætningen med 1 procent. LinkedIn Post (Amazon-Zitat, weiterverbreitet)↗

Vi bruger ikke sådanne tal til at lægge pres på, men til at afklare prioriteten: Hvis dit kritiske øjeblik er konverteringen, så er skalerbarhed ikke et „tech-ekstra“, men beskyttelse af din værdiskabelse.

Og endnu en ting, der i praksis gør forskellen: Målbarhed er også beroligelse. Når du har monitoring og belastningstests, behøver du ikke håbe. Du kan vide.

Et peak rammer altid den smalleste del

Når apps går i stykker „under belastning“, ser det udefra ofte ud som ét enkelt problem: „Server overbelastet.“ I virkeligheden er det næsten altid en kæde af flaskehalse.

Helt klassisk er det databasen. I begyndelsen er den praktisk: ét centralt sted, alt konsistent, alt efterprøvbart. Og så kommer det øjeblik, hvor en enkelt forespørgsel pludselig kører tusind gange oftere. Eller en lock blokerer skriveadgange. Eller et dårligt valgt indeks gør en søgning til en fuldtekst-vandring.

Mindst lige så ofte er det koden. Ikke „programmeret for langsomt“, men for tæt koblet. En funktion kalder tre andre, venter på en ekstern API og skriver samtidig logs synkront. Det fungerer med 50 brugere. Med 5.000 bliver det en dominoeffekt.

Og så er der den flaskehals, som næsten ingen taler om først: Processer og releases. Hvis en hotfix kun kan implementeres om natten, hvis deployments gør dig nervøs, hvis ingen præcist ved, hvad der skal overvåges efter releasen – så er det ikke systemet, der skalerer, men stressniveauet.

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

I praksis bruger vi gerne et lille princip til dette, som du kan tage med dig med det samme: „Gør det kritiske kort.“ Alt, hvad dit kritiske øjeblik er (registrering, checkout, donation), bør have så få afhængigheder som muligt. Hvis du bagefter stadig vil sende mails, generere PDF'er eller opdatere statistikker, så gør det asynkront.

Her bliver det også tydeligt, hvorfor mange nedbrud er så dyre: Downtime er ikke kun en teknisk tilstand, men også en forretningsmæssig skade. Atlassian nævner eksempler, hvor nedbrud hos store virksomheder har forårsaget skader på tocifrede millionbeløb. Atlassian↗

Du behøver ikke være Facebook for at mærke denne effekt. Mindre produkter har bare mindre buffer.

Mere kraft og flere instanser løser forskellige problemer

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

Vertikal betyder: Du giver et system mere kraft. Mere CPU, mere RAM, et større database-setup. Det er ofte det første skridt, fordi det virker hurtigt og kræver få ændringer. Men vertikal skalering har grænser: på et tidspunkt bliver det meget dyrt, og du har stadig et centralt punkt, der kan fejle.

Horisontal betyder: Du fordeler belastningen på flere instanser. Ikke én stærkere server, men flere – ideelt set sådan, at du automatisk kan skalere op ved peaks og ned igen i perioder med ro.

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

I praksis er skalering ofte en blanding: Lidt vertikalt for hurtigt at få luft, og målrettet horisontalt dér, hvor det virkelig tæller.

Det, vi altid tænker med: Pålidelighed er en søskende til skalerbarhed. Så snart du arbejder horisontalt, indbygger du ofte automatisk redundans. Hvis en instans fejler, overtager andre. Det er ikke kun „mere ydeevne“, men mindre risiko.

Og her kommer vores Pola-perspektiv ind: Vi bryder os ikke om „konstant maksimal ydeevne“. Det bliver bæredygtigt, når dit system er elastisk. Ekstra ressourcer kun, når der er brug for dem. Det sparer omkostninger og undgår unødvendigt energiforbrug – den tekniske side af en holdning: ikke at spilde.

Hvis du lige er begyndt, er den vigtigste beslutning derfor ikke „Kubernetes eller ej“, men: Kan din app grundlæggende håndtere flere instanser? Hvis du forbereder det ordentligt, holder mange muligheder åbne for dig.

Den enkleste bæredygtige vej er ofte den bedste

Arkitekturspørgsmålet bliver ofte ført unødigt ideologisk: Monolit dårlig, microservices god. Vi ser anderledes på det. For mange produkter er en velbygget monolit helt rigtig i begyndelsen: hurtigere at implementere, lettere at teste, lettere at forstå.

Problemet er sjældent monolitten i sig selv, men en monolit uden grænser. Hvis alt kender alt, bliver enhver ændring dyr.

Derfor bruger vi gerne en anden gennemprøvet metode: „Skær efter ansvar, ikke efter teknik.“ Konkret betyder det: Vi strukturerer tidligt efter faglige områder, så du senere kan trække enkelte dele ud uden at rive hele produktet fra hinanden.

En typisk vej ser sådan ud:

• Start som en modulær monolit med klare domæner (f. eks. konti, indhold, betalinger).
• Når et domæne vokser kraftigt eller får særlige krav, udskilles det som en selvstændig 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 ganske vist giver dig mulighed for at drive dele uafhængigt, men de medfører nye opgaver: netværkskommunikation, distribueret fejlfinding, versionsstyring, observability. Det kan betale sig, når kompleksiteten alligevel er der – ikke for at „købe“ kompleksitet.

Her passer også en vigtig advarsel fra startup-konteksten: Der er tegn på, at en stor del af startup-fejl hænger sammen med for tidlig skalering – ofte organisatorisk og strategisk, men tankegangen kan overføres. LinkedIn Post (Startup Genome Zahl, weiterverbreitet)↗

Vores holdning til det: Planlæg døren, byg ikke hele huset med det samme. En app må gerne starte som en MVP. Men den bør bygges sådan, at du ikke skal begynde forfra ved hvert væksttrin.

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

Caching og afkobling skaber målrettede reserver

Når vi pragmatisk forbedrer skalerbare apps, starter vi sjældent med „store“ ombygninger. Som regel giver nogle få målrettede byggesten straks stabilitet – og de passer også til en bæredygtig tankegang, fordi de reducerer ressourcespild.

Caching er ofte det første. Hvis 10.000 mennesker åbner den samme startside, bør dit system ikke udføre det samme arbejde 10.000 gange. En cache (for eksempel Redis) gemmer ofte anvendte data i hukommelsen og aflaster database og backend.

CDN'er er den anden klassiker. Billeder, assets, nogle gange endda dele af API-svar kan leveres tættere på brugeren. Det sænker latenstiden og reducerer belastningen på kernesystemet. For mange teams er Cloudflare en hurtig indgang, fordi du kan kombinere CDN, caching og beskyttelsesfunktioner godt.

Køer er vores yndlingsbyggesten, når peaks er uforudsigelige. I stedet for at ville klare alt med det samme, tager du imod opgaver og behandler dem i baggrunden. Det udjævner belastningsspidser og gør dit system „mere tålmodigt“. Teknisk kan det ske med RabbitMQ eller – i større skala – med Apache Kafka .

Og så er der databasestrategier: Replikering for mere læsekapacitet, gode indekser, nogle gange partitionering. Det er mindre glamourøst end microservices, men ofte det punkt, hvor der virkelig sker noget.

Rækkefølgen er ikke noget dogme, snarere en observation: Gør først det åbenlyse effektivt, og fordel derefter.

Vores friske perspektiv på det: Grøn vækst er ofte ganske enkelt god engineering. En arkitektur, der kun skalerer op efter behov, er som regel billigere – og den bruger mindre energi end et system, der konstant kører i maksimal størrelse. Scand beskriver også skalerbarhed som ressourceeffektivitet: Ressourcer tilkobles kun, når belastningen stiger. Scand↗

Hvis du arbejder purpose-drevet, er det et stille, men vigtigt punkt: Dit produkt kan vokse, uden at din drift „vokser med“ som et konstant bål.

Uden tests forbliver robusthed kun en antagelse

Skalerbarhed opstår ikke kun under opbygningen, men især under driften. Vi har for ofte set, at teams „egentlig“ var godt rustet – og så manglede præcis det, der ville have gjort peaken kontrollerbar: en test, en alarm, en klar rutine.

Belastningstests lyder som luksus. I virkeligheden er de ofte det billigste realitetstjek, du kan få. Miquido formulerer det pragmatisk: Om en app kan vokse, viser sig først gennem load- og performance-tests. Miquido↗

Hvis du leder efter et værktøj, der passer godt ind i moderne pipelines, kan vi godt lide k6 meget: scriptbaseret, let at automatisere, klart output. Til mere klassiske setups er JMeter eller Gatling også solide.

Monitoring er den anden del af ligningen. Ikke kun „CPU er høj“, men: Hvilke endpoints bliver langsomme? Hvilke DB-queries dominerer? Hvor stiger fejlprocenterne? Til det har du brug for observability – metrikker, logs og (i distribuerede systemer) traces. En velafprøvet open-source-duo er Prometheus plus Grafana. Hvis du vil være hurtigere klar, er værktøjer som Datadog eller New Relic ofte pragmatiske.

Og så kommer incident-readiness: Hvad sker der, når det virkelig brænder på?

Vi holder det gerne enkelt og øver tre ting med teams:

1) En release kræver observation. Hvilke metrikker tjekker vi i de første 30 minutter?

2) Alarmer skal gøre det muligt at handle. Hellere få, der er rigtige, end mange, der bliver ignoreret.

3) Rollback er en feature. Hvis det er svært at rulle tilbage, bliver hver opdatering risikabel.

Hvad det har med Pola at gøre: Vores arbejde slutter ikke ved launch. Vi tænker performance, vedligeholdbarhed og drift sammen – fordi skalerbarhed først er ægte, når den skaber ro i hverdagen. Og ro er i sidste ende et kvalitetskendetegn, som brugerne mærker, uden at kunne sætte ord på det.