Enostavno širjenje
Zgrajeno za rast od prvega dne z razširljivo arhitekturo in globalnim dosegom
Modularna in ločena arhitektura
Vemo, da so tesno povezani sistemi krhki sistemi. Uporabljajo se mikro-moduli ali struktura, ki temelji na storitvah, tudi če je monolit. Grupiranje se izvaja po funkcionalnostih/domenah, ne po tehnoloških plasteh (Domain-Driven Design lite). Frontend/backend sta ločena preko API pogodb (OpenAPI, GraphQL). Prednosti: Enostavno izolirati, razširiti ali zamenjati module, ne da bi pri tem poškodovali celoten sistem.
Razširljiv tehnološki sklad (Pravi orodja za pravo delo)
Izbiramo razširljive univerzalne izvajalce (predvsem Node.js) za backend. PostgreSQL, oblačne PostgreSQL združljive baze podatkov, Supabase, Firebase se uporabljajo po potrebi. Redis je integriran za težke bralne obremenitve ali predpomnjenje. Uporabljamo oblačno-native infrastrukturo in docker: AWS / GCP / — z podporo za samodejno skaliranje. Orodja, ki se ne morejo horizontalno razširiti ali nimajo podpore skupnosti, se izogibamo.
Asinhroni + delovni tokovi na osnovi čakalnih vrst za nekritične naloge
Vemo, da se vse ne potrebuje zgoditi v realnem času. Dolgotrajne ali naloge v ozadju (e-pošta, obdelava slik, obračunavanje) se prenesejo na čakalne vrste itd. Primer: Po tem, ko se uporabnik prijavi, se obračunavanje/e-pošta obdelata v ozadju, ne v vrstici. To pomaga pri boljši zmogljivosti in razširljivosti.
Model podatkov in oblikovanje API-jev zgrajena za razvoj
Vemo, da slaba shema = prihodnje delo. Različne API-je (/api/v1/...) se uporabljajo za preprečevanje poškodovanja strank. UUID-ji so prednostni pred inkrementalnimi ID-ji (npr. za združevanje podatkov med regijami). Načrtovana je večnajemniška arhitektura (še posebej v SaaS): ločevanje na ravni vrstic proti ločevanju na ravni sheme, dodajte tenant_id zgodaj.
Nadzor, opazovanje in opozorila od prvega dne
Vemo, da ne morete razširiti tistega, česar ne vidite. Orodja, kot je Sentry, se uporabljajo za sledenje napakam na sprednjem delu; Prometheus za opazovanje v ozadju/infrastrukture; PostHog, Google Analytics za analitiko izdelkov; Nenehno preverjanje za spremljanje izpadov. Opozorila (Slack/e-pošta) so nastavljena za zrušitve, zamude v čakalnih vrstah, spike DB itd.
Horizontalna razširljivost in brezstanje storitve
Vemo, da se monoliti lahko razširijo, vendar se brezstanje storitve razširijo bolje. Shranjevanje uporabniških sej v lokalni pomnilnik se izogibamo — uporabljajo se Redis/sejne shrambe. Strežniki so narejeni brezstanje, da jih je mogoče enostavno podvojiti. Uporablja se kontejnerizacija: Docker + orkestratorji (oblačni ponudniki). To omogoča samodejno razširitev brez lepljenih sej ali ozkih grl v skupni pomnilnik.
Varnost in nadzor dostopa pri razširljivosti
Vemo, da več uporabnikov = več napadnih površin. Nastavljeni so RBAC/ABAC vzorci (nadzor dostopa na osnovi vlog). Uporabljajo se omejevanje hitrosti, validacija vhodnih podatkov in varnostne glave. Skrivnosti se hranijo v zakladnicah in se obračajo.
Najboljše prakse razširljivosti po plasteh
API plast: Omejevanje hitrosti, paginacija, GraphQL federacija (če je potrebno) so implementirani. Sprednji del: Uporablja se leno nalaganje, gostovanje CDN, delitev kode. Uporablja se samodejna razširitev. Baza podatkov: Indeksi so ponovno indeksirani, sharding je načrtovan, če je potrebno, in tako naprej.