Arhitektonske beleške iz produkcionih sistema

Arhitektonski rad ima najviše vrijednosti kada ostane blizu produkcionih ograničenja. Najčistiji dijagram nije cilj sam po sebi. Cilj je sistem koji tim može izgraditi, operisati, objasniti i mijenjati kada se zahtjevi pomjere.

Ove beleške sumiraju obrasce odluka kojima se stalno vraćam kroz backend sisteme, cloud platforme, data proizvode i tehničko vođstvo.

Prvo granice, ne servisi

Prvo arhitektonsko pitanje obično nije da li sistem treba biti monolit ili mikroservisi. Bolje prvo pitanje je gdje su poslovne granice i koji podaci moraju da se mijenjaju zajedno.

Modularni monolit je često jak početni izbor kada timu trebaju brza isporuka, jasno vlasništvo nad domenom i transakciona konzistentnost. On dozvoljava da kod izrazi granice modula bez toga da svaka granica odmah postane mrežna granica. To je važno kada proizvod još uči i kada se domenska pravila i dalje mijenjaju.

Odvojeni servisi postaju korisniji kada se životni ciklus, skaliranje, vlasništvo, bezbjednost ili integracioni zahtjevi stvarno razlikuju. Identity je čest primjer. Autentifikacija i autorizacija često imaju drugačiji release ciklus, compliance profil i integracioni roadmap od glavnog product workflow-a. Izdvajanje tog dijela ranije može opravdati dodatni operativni trošak.

Koristiti event-e tamo gdje smanjuju spregu

Event-driven arhitektura je vrijedna kada razdvaja module koji ne treba da blokiraju jedni druge. Rizicna je kada postane zamjena za razumijevanje transakcionih granica.

Inbox i Outbox pattern-i su korisni jer čine failure model eksplicitnim. Sistem može u istoj transakciji sačuvati poslovnu promjenu i namjeru da objavi event. Dispatcher može objaviti kasnije. Consumer može zapisati identifikatore obrađenih poruka. Tako retry, duplirana isporuka i replay postaju dio dizajna umjesto kasnog produkcionog iznenađenja.

Isti pattern je još važniji u offline-first sistemima. Kada se laboratorija, uređaj ili edge instalacija ponovo povežu nakon prekida, arhitektura mora očekivati zakašnjele i ponovljene poruke. Idempotentni handler-i i jasno vlasništvo nad stanjem nisu detalji koji se mogu ostaviti za kraj.

Cloud odluke su operativne odluke

Izbor između App Services, AKS, Container Apps, Functions, ECS, EKS ili Fargate nije samo hosting odluka. On mijenja deployment kompleksnost, skaliranje, observability, trošak i vjestine koje tim mora imati.

Za male servise sa jednostavnim trigger-ima, serverless funkcije mogu smanjiti operativno opterećenje. Za duže servise sa predvidivim saobraćajem, container platforme daju bolju kontrolu. Za složene multi-service platforme, Kubernetes može biti dobar izbor, ali samo kada je tim spreman da posjeduje tu operativnu površinu.

Najpouzdaniji cloud razgovori rano uključuju trošak i on-call realnost. Tehnicki elegantan dizajn koji niko ne može sigurno operisati nije završena arhitektura.

Performanse moraju biti mjerljive

Optimizacija treba konkretan cilj. Kod queue-based workload-a, CPU sam po sebi često nije dobar signal. Dužina reda, throughput worker-a, vrijeme podizanja podova, provider kvote i ukupno vrijeme završetka često pokazuju stvarnu sliku.

Kod web proizvoda, Core Web Vitals treba posmatrati kao signale korisničkog iskustva, ne samo kao SEO metrike. LCP, INP i CLS pokazuju da li se stranica brzo učitava, reaguje na interakciju i ostaje vizuelno stabilna. Najbolji popravci često dolaze iz rezervisanih dimenzija slika, manjeg broja client-side zavisnosti, server renderinga gdje ima smisla i izbjegavanja teških third-party skripti.

Dokumentacija treba objasniti odluke

Arhitektonska dokumentacija treba sačuvati zašto je odluka donesena, ne samo kako finalni oblik izgleda. C4 dijagram, kratak ADR ili delivery beleška su korisni kada budućem inženjeru objasne ograničenja, tradeoff-e i odbijene opcije.

Dokumentacija ne mora biti teska. Mora biti dovoljno azurna da sprijeci ponavljanje istih rasprava i dovoljno konkretna da vodi sljedecu implementacionu odluku.

Vodstvo je dio arhitekture

Arhitektura nije zapisana samo u kodu i dijagramima. Vidi se i u obliku backlog-a, planiranju sprinta, navikama pregleda, mentorstvu i discovery radionicama. Dobra arhitektura koju tim ne može izvesti i dalje će propasti.

Praktičan posao je da sistem ostane razumljiv, da tim bude usklađen oko granica i da tradeoff-i budu vidljivi prije nego što postanu produkcioni incidenti.