Jednostavno skaliranje
Izgrađeno za rast od prvog dana s skalabilnom arhitekturom i globalnim dosegom
Modularna i odvojena arhitektura
Znamo da su čvrsto povezani sustavi krhki sustavi. Mikro-moduli ili struktura temeljena na uslugama koriste se čak i ako je monolit. Grupiranje se vrši prema značajkama/domenama, a ne prema tehničkim slojevima (lagani dizajn vođen domenom). Frontend/backend su odvojeni putem API ugovora (OpenAPI, GraphQL). Prednosti: Lako izolirati, skalirati ili zamijeniti module bez razbijanja cijelog sustava.
Skalabilni tehnološki skup (Pravi alati za pravi posao)
Biramo skalabilne univerzalne runtime-ove (pretežno Node.js) za backend. PostgreSQL, cloud PostgreSQL kompatibilne baze podataka, Supabase, Firebase koriste se ako je potrebno. Redis je integriran za intenzivni promet čitanja ili keširanje. Koristi se cloud-native infrastruktura i docker: AWS / GCP / — s podrškom za automatsko skaliranje. Nejasni alati koji ne mogu horizontalno skalirati ili nemaju podršku zajednice se izbjegavaju.
Asinkroni + radni tokovi temeljeni na redovima za ne-kritične zadatke
Znamo da se sve ne mora događati u stvarnom vremenu. Dugotrajni ili pozadinski zadaci (e-pošta, obrada slika, naplata) prebacuju se na redove itd. Primjer: Nakon što se korisnik prijavi, naplata/e-pošta se obrađuje u pozadini, a ne u liniji. To pomaže u boljoj izvedbi i skalabilnosti.
Model podataka i dizajn API-ja izgrađeni za evoluciju
Znamo da loša shema = budući rad. Verzijski API-ji (/api/v1/...) koriste se za sprječavanje prekida klijenata. UUID-ovi su favorizirani u odnosu na inkrementalne ID-ove (npr. za spajanje podataka između regija). Planira se višekorisnički pristup (posebno u SaaS): Odvajanje na razini redaka naspram odvajanja na razini sheme, dodajte tenant_id rano.
Praćenje, uočljivost i obavijesti od prvog dana
Znamo da ne možete skalirati ono što ne možete vidjeti. Alati poput Sentry koriste se za praćenje grešaka na frontend-u; Prometheus za uočljivost backend-a/infrastrukture; PostHog, Google analytics za analitiku proizvoda; Kontinuirani pregledi za praćenje vremena neaktivnosti. Obavijesti (Slack/email) postavljene su za rušenja, zastoje u redovima, spike-ove u bazi podataka itd.
Horizontalna skalabilnost i stateless usluge
Znamo da monoliti mogu skalirati, ali stateless usluge skaliraju bolje. Izbjegava se pohranjivanje korisničkih sesija u lokalnu memoriju — koriste se Redis/session pohrane. Poslužitelji su napravljeni bez stanja kako bi se mogli lako duplicirati. Koristi se kontejnerizacija: Docker + orkestratori (cloud pružatelji). To omogućuje automatsko skaliranje bez sticky sesija ili uskih grla u dijeljenju memorije.
Sigurnost i kontrola pristupa na velikoj skali
Znamo da više korisnika = veća površina za napad. Postavljeni su RBAC/ABAC obrasci (kontrola pristupa temeljena na ulogama). Primjenjuju se ograničenja brzine, validacija ulaza i sigurnosni zaglavlja. Tajne se čuvaju u trezorima i rotiraju.
Najbolje prakse skalabilnosti po sloju
API sloj: Ograničenja brzine, paginacija, GraphQL federacija (ako je potrebno) su implementirani. Frontend: Lazy loading, CDN hosting, dijeljenje koda se koristi. Koristi se automatsko skaliranje. Baza podataka: Indeksi se reindeksiraju, sharding je planiran ako je potrebno, i tako dalje.