Viegli paplašināms
Izveidots izaugsmei no pirmās dienas ar mērogojamu arhitektūru un globālu sasniedzamību
Modulāra un atdalīta arhitektūra
Mēs zinām, ka cieši saistīti sistēmas ir trauslas sistēmas. Mikro moduļi vai pakalpojumu balstīta struktūra tiek izmantota pat monolīta gadījumā. Grupēšana tiek veikta pēc funkcijām/domenēm, nevis tehnoloģiju slāņiem (Domain-Driven Design lite). Frontend/backend ir atdalīti, izmantojot API līgumus (OpenAPI, GraphQL). Priekšrocības: viegli izolēt, mērogot vai aizstāt moduļus, nepārtraucot visu sistēmu.
Mērogojama tehnoloģiju kaudze (Pareizie rīki pareizajam darbam)
Mēs izvēlamies mērogojamus universālus izpildes laikus (galvenokārt Node.js) backend. PostgreSQL, mākoņa PostgreSQL saderīgas datubāzes, Supabase, Firebase tiek izmantotas, ja nepieciešams. Redis tiek integrēts smagas lasīšanas plūsmas vai kešatmiņas gadījumā. Tiek izmantota mākoņiem raksturīga infrastruktūra un docker: AWS / GCP / — ar automātiskās mērogošanas atbalstu. Tiek izvairīts no neskaidriem rīkiem, kas nevar horizontāli mērogot vai kuriem trūkst kopienas atbalsta.
Asinhroni + rindas balstīti darba plūsmām nekritiskām uzdevumiem
Mēs zinām, ka viss nenotiek reāllaikā. Ilgstoši vai fona uzdevumi (e-pasti, attēlu apstrāde, rēķināšana) tiek novirzīti uz rindām utt. Piemērs: Pēc tam, kad lietotājs reģistrējas, rēķināšana/e-pasts tiek apstrādāts fona režīmā, nevis tiešsaistē. Tas palīdz uzlabot veiktspēju un mērogojamību.
Datu modelis un API dizains, kas izstrādāts, lai attīstītos
Mēs zinām, ka slikta shēma = nākotnes pārbūve. Versiju API (/api/v1/...) tiek izmantoti, lai novērstu klientu pārtraukšanu. UUID tiek priekšroka pār inkrementālajiem ID (piemēram, datu apvienošanai starp reģioniem). Plānots daudznomnieku atbalsts (īpaši SaaS): rindu līmeņa pret shēmas līmeņa atdalīšanu, pievienot tenant_id agri.
Uzraudzība, novērojamība un brīdinājumi no pirmās dienas
Mēs zinām, ka jūs nevarat palielināt to, ko neredzat. Rīki kā Sentry tiek izmantoti frontend kļūdu izsekošanai; Prometheus backend/infrastruktūras novērojamībai; PostHog, Google analytics produktu analīzei; Turpinājuma pārbaudes dīkstāves uzraudzībai. Brīdinājumi (Slack/e-pasts) tiek iestatīti avārijām, rindas kavējumiem, DB pieaugumiem utt.
Horizontālā mērogojamība un bezstāvokļa pakalpojumi
Mēs zinām, ka monolīti var mērogot, bet bezstāvokļa pakalpojumi mērogot labāk. Lietotāju sesiju glabāšana lokālajā atmiņā tiek izvairīta — tiek izmantoti Redis/sesiju krātuves. Serveri tiek padarīti par bezstāvokļa, lai tos varētu viegli dublēt. Tiek izmantota konteinerizācija: Docker + orķestratori (mākoņu pakalpojumu sniedzēji). Tas ļauj automātiski mērogot bez lipīgām sesijām vai kopētas atmiņas šaurumiem.
Drošība un piekļuves kontrole mērogā
Mēs zinām, ka vairāk lietotāju = lielāka uzbrukuma virsma. RBAC/ABAC modeļi (lomu balstīta piekļuves kontrole) ir iestatīti. Tiek piemēroti ātruma ierobežojumi, ievades validācija un drošības galvenes. Noslēpumi tiek glabāti seifos un rotēti.
Mērogojamības labākās prakses katrā slānī
API slānis: ātruma ierobežojumi, lapu sadalīšana, GraphQL federācija (ja nepieciešams) ir ieviesta. Frontend: slinks ielāde, CDN mitināšana, koda sadalīšana tiek izmantota. Tiek izmantota automātiskā mērogošana. Datu bāze: indeksi tiek atkārtoti indeksēti, sharding tiek plānots, ja nepieciešams, un tā tālāk.