1 
2Når en webapplikation vokser i brugere, data og funktioner, bliver skalerbarhed en prioritet. I denne artikel analyserer vi de vigtigste strategier og mønstre for skalering af en webapplikation.
3 
4## Vertikal vs horisontal skalerbarhed
5 
6```mermaid
7flowchart LR
8    A[Users] --> B[Load Balancer]
9    B --> S1[Server 1]
10    B --> S2[Server 2]
11    B --> S3[Server 3]
12```
13 
14- **Vertikal:** enkel at implementere, men med fysiske grænser.
15- **Horisontal:** mere modstandsdygtig og skalerbar.
16 
17## Caching: Hurtigere svar
18 
19```mermaid
20flowchart TD
21    U[User] --> CDN[CDN]
22    CDN --> App[Application]
23    App --> DB[Database]
24```
25 
26- **Klientside cache:** browser, service worker.
27- **Serverside cache:** Redis, Memcached.
28- **CDN:** distribuerer statisk indhold på globale servere.
29 
30## Load Balancing: Fordeling af trafik
31 
32```mermaid
33flowchart TD
34    U[User] --> LB[Load Balancer]
35    LB --> S1[Server 1]
36    LB --> S2[Server 2]
37    LB --> S3[Server 3]
38```
39 
40- **Algoritmer:** Round Robin, Least Connections, IP Hash.
41- **Værktøjer:** NGINX, HAProxy, AWS ELB.
42 
43## Databaseskalering: Replikering og sharding
44 
45```mermaid
46flowchart TD
47    App[Application] --> DB1[Shard 1]
48    App --> DB2[Shard 2]
49    App --> DB3[Shard 3]
50```
51 
52- **Replikering:** skrivebeskyttede kopier til at fordele forespørgselsbelastning.
53- **Sharding:** opdeling af data på tværs af flere databaser.
54- **NoSQL-databaser:** designet til horisontal skalering.
55 
56## Microservices og distribuerede arkitekturer
57 
58```mermaid
59flowchart TD
60    U[User] --> API[API Gateway]
61    API --> MS1[Microservice 1]
62    API --> MS2[Microservice 2]
63    API --> MS3[Microservice 3]
64    MS1 --> DB1[(DB 1)]
65    MS2 --> DB2[(DB 2)]
66    MS3 --> DB3[(DB 3)]
67```
68 
69## Asynkronitet og arbejdskøer
70 
71```mermaid
72flowchart TD
73    App[Application] -- send task --> Queue[Queue]
74    Queue --> Worker[Worker]
75    Worker --> DB[Database]
76```
77 
78## Overvågning og auto-skalering
79 
80- **Metrics:** CPU, RAM, latens, fejl.
81- **Auto-skalering:** automatisk tilføjelse/fjernelse af ressourcer.
82 
83## Almindelige skalerbarhedsmønstre
84 
85- **Strangler Fig Pattern:** gradvis migration fra monolit til microservices.
86- **CQRS:** adskiller læsninger og skrivninger.
87- **Event Sourcing:** applikationstilstand håndteres via hændelser.
88 
89## Avancerede skalerbarhedsmønstre
90 
91- **Circuit Breaker:** forhindrer kaskadesvigt.
92- **Bulkhead:** isolerer ressourcer mellem komponenter.
93- **Retry og Backoff:** automatisk genforsøg med stigende intervaller.
94- **Rate Limiting:** begrænser antallet af anmodninger.
95 
96```mermaid
97flowchart TD
98    Client --> API[API Gateway]
99    API --> CB[Circuit Breaker]
100    CB --> Svc[Service]
101    Svc --> DB[Database]
102    API --> RL[Rate Limiter]
103    RL --> CB
104```
105 
106## Teknologistakke fra den virkelige verden
107 
108- **Netflix:** microservices, auto-skalering på AWS, Circuit Breaker (Hystrix).
109- **Amazon:** massiv database-sharding, flerlagede load balancere.
110 
111## Almindelige fejl og bedste praksis
112 
113**Hyppige fejl:**
114- Kun at stole på vertikal skalering.
115- Ikke at overvåge nøglemetrics.
116- Ikke at teste skalering under reel belastning.
117 
118**Bedste praksis:**
119- Automatiser deployment og skalering.
120- Isoler kritiske tjenester.
121- Implementer logging, tracing og alerting.
122- Test regelmæssigt med simulerede belastninger.
123 
124## Komplet anmodningsflow i en skalerbar arkitektur
125 
126```mermaid
127flowchart LR
128    U[User] --> CDN[CDN]
129    CDN --> LB[Load Balancer]
130    LB --> API[API Gateway]
131    API --> MS[Microservices]
132    MS --> MQ[Message Queue]
133    MS --> Redis[Cache]
134    MS --> DB[Database]
135    MQ --> Worker[Worker]
136    Worker --> DB
137```
138 
139## Konklusion
140 
141At skalere en webapplikation kræver en holistisk vision: arkitektur, værktøjer, automatisering, overvågning og DevOps-kultur. At studere avancerede mønstre og lære af store virksomheders fejl er nøglen til at bygge modstandsdygtige systemer.
142