Vad betyder skalbarhet vid utveckling av en app?

Ibland växer det smygande: Appen känns ”lite” långsammare, supportärenden hopar sig och releasedagar blir nervösa.

Och ibland kommer den som en smäll. En kampanj drar igång, en pressnämning ger en topp, eller ditt Purpose-projekt delas i ett nyhetsbrev. Från 500 dagliga användare blir det 50.000 – inte över ett år, utan över en helg.

I våra projekt ser vi: Skalbarhet blir sällan viktig av teknik-kärlek, utan av förtroende-kärlek. När en app vacklar under last, händer inte bara ”ett fel”. Det händer något i huvudet: Människor ger upp, recensioner sjunker, team hamnar i krisläge.

Förväntningen är brutalt ärlig. Redan vid mobila webblösningar visas hur lite tålamod det finns: Över 53 procent lämnar en sida om den tar längre än tre sekunder att ladda. Marketing Dive (Google-studie, 2016)

Även om appar inte är identiska med webbplatser – den emotionella logiken är densamma: ”Om det inte fungerar direkt, är det inte pålitligt.”

Vår första fräscha synvinkel: Skalbarhet är också effektstabilitet. Om du bygger en utbildningsapp som ska nå fler människor, eller en plattform som främjar doneringar, då är stabilitet inte bara en teknisk fråga. Det är en del av ditt ansvar: Din mission får inte misslyckas vid en överbelastad inloggningspunkt.

Därför börjar vi tidigt med en enkel, men avgörande fråga: Vad ska din app vara förberedd på – förutsägbart tillväxt, oförutsägbara toppar eller både och? Denna differentiering bestämmer senare om du framförallt prioriterar kapacitet, elasticitet eller robusthet.

När någon säger ”Vi måste bygga appen skalbar”, menar de ofta bara: ”Fler användare ska kunna komma in samtidigt.” Det är viktigt – men det är bara halva historien.

Skalbarhet har två tillväxtaxlar:

Först: Lasttillväxt. Fler samtidiga förfrågningar, mer datatrafik, fler enheter, fler av ditt systems sidouppgifter (Push, Sync, Uppladdningar). Appmarknaden växer och med den förväntan att allt helt enkelt fungerar. Enbart tätheten visar trycket: 2023 fanns det över 3,7 miljoner appar i Google Play Store och runt 1,8 miljoner i Apple App Store. Selleo

För det andra: Funktionsväxt. Nya funktioner, nya roller, nya integrationer, nya marknader. En app som började med 5 skärmar blir med tiden en produkt med regler, särskilt fall och undantag. Och precis här misslyckas mycket: Inte för att CPU:n är för svag, utan för att varje förändring plötsligt blir riskabel.

Viktigt är åtskillnaden: Skalbarhet är inte samma som prestanda. Prestanda beskriver hur snabbt något är vid en viss belastning. Skalbarhet beskriver hur bra appen håller sin prestation när belastningen ökar.

En bild från vardagen vi gärna använder: Prestanda är hur snabbt ett tåg går på fri väg. Skalbarhet är om tidtabellen fortfarande passar när plötsligt tre gånger så många människor stiger på – utan att dörrar klämmer, signaler faller eller hela verksamheten stannar.

Vår andra fräscha synvinkel: Skalbarhet är teamvänlig arkitektur. I praktiken växer inte bara appen, utan också teamet som arbetar med den. Om flera utvecklare ska leverera samtidigt behöver du strukturer som frigör reformer från varandra. En ”skalbar app” betyder därför också: lätt att testa, modulär, förståelig.

Om du namnger dessa två axlar tidigt, blir beslut lättare: Vissa projekt behöver först lastreserver, andra först en ren grund för funktionsväxt. Och ofta är det en mix – men med tydlig viktning.

När appar ”går sönder” under belastning, verkar det ofta utåt som ett enda problem: ”Server överbelastad.” I verkligheten är det nästan alltid en kedja av flaskhalsar.

Klassisk är databasen. I början är den bekväm: en central plats, allt konsekvent, allt spårbart. Och då kommer ögonblicket när en enda fråga plötsligt körs tusentals gånger oftare. Eller ett lås blockerar skrivåtkomst. Eller en dåligt vald index gör en sökning till en heltextvandring.

Minst lika vanligt är det koden. Inte ”för långsamt skriven” utan för tätt kopplad. En funktion kallar tre andra, väntar på ett externt API och skriver samtidigt loggar synkront. Det fungerar med 50 användare. Med 5.000 blir det en dominoeffekt.

Och sedan finns det flaskhalsen som knappt någon pratar om först: Processer och releaser. Om en hotfix bara kan spelas in på natten, om release skrämmer, om ingen exakt vet vad som måste observeras efter release – då skalar inte systemet, men stressnivån.

Vår tredje fräscha synvinkel: Skalbarhet är incidentvänlighet. Vi bygger inte bara för ”mer”, vi bygger för ”när något går fel”. Det är en tyst skillnad: En robust app har klara gränser, klara tidsgränser, klara fallback. Och den hjälper teamet att snabbt förstå vad som händer.

I praktiken använder vi gärna ett litet princip som du omedelbart kan ta med: ”Gör det kritiska kort.” Allt som är ditt kritiska moment (registrering, checkout, donation), borde ha så få beroenden som möjligt. Om du efteråt vill skicka mail, generera PDF-filer eller uppdatera statistik, gör det asynkront.

Här visas också varför många avbrott är så dyra: Driftstopp är inte bara ett tekniskt tillstånd, utan en affärsskada. Atlassian ger exempel där avbrott hos stora företag har orsakat skador i tiotals miljoner. Atlassian

Du behöver inte vara Facebook för att känna denna effekt. Mindre produkter har bara mindre buffertar.

När vi talar om skalning, kommer vi snabbt till två grundmodeller: vertikal och horisontell.

Vertikal innebär: Ge ett system mer kraft. Mer CPU, mer RAM, en större databaskonfiguration. Det är ofta det första steget, eftersom det verkar snabbt och kräver lite ombyggnad. Men vertikal skalning har gränser: det blir mycket dyrt, och du har fortfarande en central punkt som kan misslyckas.

Horisontell betyder: Fördela lasten över flera instanser. Inte en starkare server utan flera – helst så att du vid toppar kan skala upp automatiskt och åter skala ner vid lugna tider.

För att horisontell ska fungera behöver du oftast två saker: en lastbalanserare (som fördelar trafiken) och tjänster som är tillståndsfri. Det låter tekniskt, men är lätt att förstå: Om en användarinloggning bara fungerar på server A för att sessionen ligger där, kan server B inte hjälpa. Om tillståndet istället ligger i ett gemensamt minne (t.ex. i en databas eller cache som Redis), kan valfria instanser ta över.

I praktiken är skalning ofta en mix: Lite vertikal för att snabbt få utrymme, och riktad horisontell där det verkligen räknas.

Vad vi alltid överväger: Tillförlitlighet är en syskon till skalbarhet. Så snart du arbetar horisontellt, bygger du ofta redundans automatiskt. Om en instans misslyckas, tar andra över. Det är inte bara ”mer prestanda”, utan mindre risk.

Och här kommer vår Pola-perspektiv in: Vi gillar inte ”konstant maximal prestation”. Hållbart blir det när ditt system är elastiskt. Ytterligare resurser bara när de behövs. Det sparar kostnader och undviker onödig energiförbrukning – den tekniska sidan av en attityd: slösa inte.

Om du precis är i början är den viktigaste beslutet därför inte ”Kubernetes eller inte”, utan: Kan din app överhuvudtaget hantera flera instanser? Om du förbereder det ordentligt, har du många vägar öppna.

Arkitekturfrågan förs ofta onödigt ideologiskt: Monolit dåligt, mikrotjänster bra. Vi ser det annorlunda. För många produkter är en välbyggd monolit i början precis rätt: snabbare att genomföra, lättare att testa, lättare att förstå.

Problemet är sällan monoliten i sig, utan en monolit utan gränser. Om allt känner allt, blir varje förändring dyr.

Därför använder vi gärna en andra beprövad metod: ”Dela efter ansvar, inte efter teknik.” Konkret innebär det: Vi strukturerar tidigt efter affärsområden, så att du senare kan separera vissa delar utan att bryta hela produkten isär.

En typisk väg ser ut så här:

• Start som modulär monolit med tydliga domäner (t.ex. konton, innehåll, betalningar).
• Om en domän växer starkt eller fått särskilda krav, blir den utlagd som egen tjänst.
• Först när team och drift verkligen drar nytta av det, uppstår fler oberoende tjänster.

Varför denna ordning? För att mikrotjänster tillåter dig att köra delar oberoende, men de medför nya uppdrag: nätverkskommunikation, distribuerad felsökning, versionering, observabilitet. Det lönar sig när komplexitet ändå finns – inte för att ”köpa” komplexitet.

Här passar också en viktig varning från startup-sammanhang: Det finns tecken på att en stor del av startup-misslyckanden beror på för tidig skalning – ofta organisatoriskt och strategiskt, men tanken kan överföras. LinkedIn Post (Startup Genome Number, spridd)

Vår inställning till detta: Planera dörren, bygg inte hela huset direkt. En app får starta som MVP. Men det borde byggas så att du inte behöver börja om vid varje tillväxtsteg.

Om du vill fördjupa dig i sådana beslut: Vi har också haft liknande arkitekturfrågor i app-projekt. Som där nya funktioner och användargrupper har kommit senare (t.ex. Ureka eller Aeri). Kontexten är olika varje gång – principen består: Klarhet före storlek.