Skalabilnost se rijetko dizajnira unaprijed u punom opsegu — većina timova gradi ono što treba danas, uz par ključnih odluka koje kasnije olakšaju rast. Evo principa koji čine najveću razliku kad promet naraste deset ili sto puta.
Stateless servisi kao temelj
Prvo i najvažnije pravilo: aplikacijski servisi ne bi trebali držati stanje sesije lokalno u memoriji procesa. Ako je stanje (sesija, korisnički kontekst) vezano za konkretnu instancu servera, horizontalno skaliranje — dodavanje novih instanci iza load balancera — postaje bolno ili nemoguće. Stanje treba izmjestiti u vanjski, dijeljeni sloj: Redis za sesije, bazu podataka za trajno stanje. Kad je svaka instanca servisa zamjenjiva, dodavanje kapaciteta postaje pitanje pokretanja novog kontejnera, ne arhitekturnog problema.
Baza podataka — često prvo usko grlo
Baza je najčešće prvo mjesto gdje sustav "udari u zid". Nekoliko provjerenih tehnika:
- Read replike — čitanja (koja su u većini aplikacija mnogo češća od pisanja) usmjeravaju se na replike, dok primarna baza ostaje posvećena pisanjima.
- Indeksiranje — prije bilo kakve složenije tehnike, provjerite jesu li upiti koji se najčešće izvršavaju pokriveni odgovarajućim indeksima; ovo često riješi 80% problema s performansama.
- Sharding — kad jedna baza fizički više ne stane na jedan stroj, podaci se dijele (shard) po nekom ključu (npr. ID korisnika) preko više baza. Ovo je moćna, ali i kompleksna tehnika koju vrijedi odgoditi dok stvarno nije nužna.
- Connection pooling — otvaranje nove konekcije na bazu za svaki zahtjev je skupo; pool konekcija koje se ponovno koriste drastično smanjuje latenciju.
Caching sloj
Caching je vjerojatno najisplativija investicija u skalabilnost po uloženom trudu. Redis ili Memcached ispred baze podataka za često čitane, rijetko mijenjane podatke (korisnički profili, konfiguracija, rezultati skupih upita) mogu smanjiti opterećenje baze za red veličine. Ključno je razmisliti o strategiji invalidacije unaprijed — cache koji vraća zastarjele podatke stvara suptilne bugove koje je teško pronaći.
Asinkrona obrada i message queues
Ne mora sve čekati sinkroni odgovor. Operacije koje ne trebaju trenutan rezultat — slanje e-maila, generiranje izvještaja, obrada uploadane slike — treba izbaciti iz request/response ciklusa u pozadinski red čekanja (RabbitMQ, Kafka, SQS). Ovo ne samo da ubrzava odgovor korisniku, nego i apsorbira nagle skokove prometa — poruke čekaju u redu umjesto da preplave servis izravno.
Load balancing i horizontalno skaliranje
Kad su servisi stateless, load balancer (Nginx, HAProxy, cloud-native rješenja poput AWS ALB) može distribuirati promet preko proizvoljnog broja instanci. Auto-scaling grupe zatim automatski dodaju ili uklanjaju instance na temelju metrika (CPU, broj zahtjeva, latencija), umjesto da timovi ručno procjenjuju kapacitet unaprijed.
Observability — vidjeti prije nego što pukne
Skalabilna arhitektura bez uvida u to što se stvarno događa je kockanje. Tri stupa observabilnosti — logovi, metrike i distributed tracing — omogućuju timu da pronađe usko grlo prije nego što korisnici osjete usporenje. Alati poput Prometheusa i Grafane za metrike, ili distribuiranog tracinga (OpenTelemetry, Jaeger) za praćenje zahtjeva kroz lanac mikroservisa, pretvaraju nagađanje u mjerenje.
Zaključak
Skalabilnost nije jedna velika arhitekturna odluka nego zbroj manjih, dosljednih odluka: servisi bez lokalnog stanja, baza podataka koja ima kamo rasti, cache koji apsorbira ponavljajuće upite, red čekanja koji izglađuje skokove prometa i observability koja pokazuje gdje je stvarni problem prije nego što ga korisnici prijave. Najbolji trenutak za uvođenje ovih principa je prije nego što postanu hitni.
