Lihtne skaleerida
Kasvamiseks loodud alates esimesest päevast, skaleeritava arhitektuuri ja globaalsete ulatustega
Modulaarne ja lahtiühendatud arhitektuur
Teame, et tihedalt seotud süsteemid on habras süsteem. Kasutatakse mikromooduleid või teenustepõhist struktuuri, isegi kui see on monoliitne. Rühmitamine toimub funktsioonide/valdkondade järgi, mitte tehnoloogiliste kihtide järgi (Domain-Driven Design lite). Frontendi ja backend'i vahel on lahtiühendamine API lepingute kaudu (OpenAPI, GraphQL). Eelised: Mooduleid on lihtne isoleerida, skaleerida või asendada, rikkuv kogu süsteemi.
Skaleeritav tehnoloogia virn (Õiged tööriistad õigeks tööks)
Valime skaleeritavad universaalsed tööaegade (peamiselt Node.js) backend'i jaoks. PostgreSQL, pilve PostgreSQL ühilduvad andmebaasid, Supabase, Firebase kasutatakse vajadusel. Redis on integreeritud suure lugemise liikluse või vahemälu jaoks. Kasutatakse pilvepõhist infrastruktuuri ja dockerit: AWS / GCP / — automaatse skaleerimise toega. Hämarad tööriistad, mis ei saa horisontaalselt skaleeruda või millel puudub kogukonna tugi, on välditud.
Asünkroonsed + järjekorrapõhised töövood mitte-kriitiliste ülesannete jaoks
Teame, et kõik ei pea toimuma reaalajas. Pikaajalised või taustategevused (e-kirjad, pilditöötlus, arveldamine) suunatakse järjekordadesse jne. Näide: Pärast kasutaja registreerimist töödeldakse arveldamist/e-kirju taustal, mitte reaalajas. See aitab parema jõudluse ja skaleeritavuse saavutamisel.
Andmemudel ja API disain, mis on loodud arenema
Teame, et halb skeem = tulevane ümbertegemine. Versiooniga API-d (/api/v1/...) kasutatakse klientide katkemise vältimiseks. Eelistatakse UUID-sid järk-järgult ID-de üle (nt andmete ühendamiseks erinevates piirkondades). Mitmeüürilisus on planeeritud (eriti SaaS-is): Ridade tasandi vs skeemi tasandi eraldamine, lisa tenant_id varakult.
Jälgimine, nähtavus ja teated alates esimesest päevast
Me teame, et sa ei saa skaleerida seda, mida sa ei näe. Tööriistu nagu Sentry kasutatakse frontend'i veateate jälgimiseks; Prometheus backend'i/infrastruktuuri nähtavuse jaoks; PostHog, Google Analytics tooteanalüütika jaoks; pidevad kontrollid katkestuste jälgimiseks. Teated (Slack/e-post) on seadistatud kokkuvarisemiste, järjekordade tagasilöökide, andmebaasi tipude jne jaoks.
Horisontaalne skaleeritavus ja olekuta teenused
Me teame, et monoliidid saavad skaleerida, kuid olekuta teenused skaleeruvad paremini. Kasutaja sessioonide salvestamine kohalikku mälu vältida — kasutatakse Redis'i/sessioonide salvestusi. Serverid on tehtud olekuta, et neid saaks hõlpsasti dubleerida. Kasutatakse konteineriseerimist: Docker + orkestrid (pilveteenuse pakkujad). See võimaldab automaatset skaleerimist ilma kleepuvate sessioonide või jagatud mälu kitsaskohtadeta.
Turvalisus ja juurdepääsukontroll skaalal
Me teame, et rohkem kasutajaid = rohkem rünnakupinda. On seadistatud RBAC/ABAC mustrid (rollipõhine juurdepääsukontroll). Rakendatakse kiiruspiiranguid, sisendi valideerimist ja turbepealkirju. Saladusi hoitakse seifides ja neid vahetatakse.
Parimad skaleeritavuse praktikad iga kihi jaoks
API kiht: Rakendatakse kiiruspiiranguid, lehekülgede jagamist, GraphQL'i föderatsiooni (kui vajalik). Frontend: Kasutatakse laisklaadimist, CDN-i majutust, koodijagamist. Kasutatakse automaatset skaleerimist. Andmebaas: Indeksid on uuesti indekseeritud, sharding on planeeritud, kui vajalik, jne.