Pami\u0119tam sytuacj\u0119 sprzed dw\u00f3ch lat. Firma e-commerce, kt\u00f3ra ros\u0142a 30% miesi\u0105c do miesi\u0105ca. W pewnym momencie aplikacja zacz\u0119\u0142a zwalnia\u0107 \u2013 czas \u0142adowania wzr\u00f3s\u0142 z 1,5 do 5 sekund. Zesp\u00f3\u0142 w po\u015bpiechu dokupi\u0142 serwery, ale to nie pomog\u0142o. Klienci narzekali, konwersja spad\u0142a o 20 proc. Problemem nie by\u0142a moc obliczeniowa \u2013 to architektura aplikacji nie by\u0142a gotowa na skalowanie. Wsp\u00f3\u0142czu\u0142em im, bo sam pope\u0142ni\u0142em podobne b\u0142\u0119dy.<\/p>\n
Skalowanie to nie tylko dodanie kolejnych instancji. To spos\u00f3b, w jaki projektujesz komunikacj\u0119 mi\u0119dzy serwisami, zarz\u0105dzasz stanem i obs\u0142ugujesz obci\u0105\u017cenie. W tym artykule poka\u017c\u0119 trzy najcz\u0119stsze b\u0142\u0119dy, kt\u00f3re widz\u0119 w firmach od startup\u00f3w po \u015brednie przedsi\u0119biorstwa.<\/p>\n
Wi\u0119kszo\u015b\u0107 ma\u0142ych firm zaczyna od monolitu \u2013 jednej aplikacji obs\u0142uguj\u0105cej wszystko. To naturalne, bo szybko si\u0119 wdra\u017ca. Problem pojawia si\u0119, gdy monolit ro\u015bnie. Nowe funkcje s\u0105 dodawane chaotycznie, kod staje si\u0119 g\u0119st\u0105 pl\u0105tanin\u0105 zale\u017cno\u015bci. Przyk\u0142ad z \u017cycia: klient z bran\u017cy logistycznej mia\u0142 monolit, kt\u00f3ry przy ka\u017cdym \u017c\u0105daniu odpytywa\u0142 baz\u0119 danych kilkana\u015bcie razy, bo logika biznesowa by\u0142a rozsiana po ca\u0142ej aplikacji. Skalowanie w poziomie (dodawanie serwer\u00f3w) tylko mno\u017cy\u0142o te zapytania, przeci\u0105\u017caj\u0105c baz\u0119.<\/p>\n
Rozwi\u0105zanie to nie musi by\u0107 od razu pe\u0142na mikrous\u0142ug. Wystarczy podzieli\u0107 monolit na modu\u0142y z jasnymi granicami. Ka\u017cdy modu\u0142 mo\u017ce by\u0107 rozwijany i skalowany niezale\u017cnie. Zastosuj podej\u015bcie domain-driven design<\/em> \u2013 wyizoluj domeny biznesowe i ogranicz ich wzajemne powi\u0105zania. Zanim zaczniesz skalowa\u0107, sprawd\u017a, ile razy jedno \u017c\u0105danie odwiedza baz\u0119. Je\u015bli wi\u0119cej ni\u017c 5, masz problem.<\/p>\n W projektowaniu aplikacji webowych cz\u0119sto zapomina si\u0119 o stanie. Gdy aplikacja dzia\u0142a na kilku instancjach, ka\u017cda ma w\u0142asn\u0105 pami\u0119\u0107. Je\u015bli u\u017cytkownik zapisze koszyk na jednej instancji, a nast\u0119pne \u017c\u0105danie trafi na inn\u0105, koszyk znika. To cz\u0119sty problem w e-commerce: porzucone koszyki, frustracja klient\u00f3w.<\/p>\n Znam firm\u0119 SaaS, kt\u00f3ra przez sze\u015b\u0107 miesi\u0119cy mia\u0142a taki problem \u2013 ka\u017cda nowa sesja powodowa\u0142a utrat\u0119 danych. Rozwi\u0105zanie? Przeniesienie stanu do zewn\u0119trznego magazynu \u2013 Redis lub baza danych. Ale uwaga: u\u017cywanie bazy relacyjnej do przechowywania sesji mo\u017ce spowolni\u0107 dzia\u0142anie, bo ka\u017cde \u017c\u0105danie odczytuje i zapisuje. Redis jest szybszy, bo dzia\u0142a w pami\u0119ci.<\/p>\n Nie zapominaj te\u017c o cache\u2019owaniu. Statyczne strony, wyniki zapyta\u0144 \u2013 to wszystko mo\u017cna przechowywa\u0107 w pami\u0119ci podr\u0119cznej. Dzi\u0119ki temu backend obs\u0142uguje mniej \u017c\u0105da\u0144, a u\u017cytkownicy szybciej dostaj\u0105 odpowiedzi. W jednym z projekt\u00f3w zmniejszyli\u015bmy obci\u0105\u017cenie bazy o 70% po wprowadzeniu cache\u2019u Redis dla cz\u0119sto u\u017cywanych danych.<\/p>\n Gdy ju\u017c podzielisz aplikacj\u0119 na modu\u0142y lub mikrous\u0142ugi, pojawia si\u0119 kolejny problem: jak te elementy rozmawiaj\u0105 ze sob\u0105. Cz\u0119sty b\u0142\u0105d to synchroniczne \u017c\u0105dania w p\u0119tli \u2013 serwis A wo\u0142a B, B wo\u0142a C, C wo\u0142a D. Je\u015bli kt\u00f3ry\u015b z nich jest wolny, ca\u0142e \u017c\u0105danie blokuje si\u0119. Klient czeka, u\u017cytkownik czeka.<\/p>\n Widzia\u0142em to w startupie fintechowym: transakcja wymaga\u0142a potwierdzenia z trzech serwis\u00f3w. Gdy jeden by\u0142 przeci\u0105\u017cony, czas realizacji r\u00f3s\u0142 z 200 ms do 5 sekund. Poprawili\u015bmy to, wprowadzaj\u0105c komunikacj\u0119 asynchroniczn\u0105 \u2013 kolejki wiadomo\u015bci (np. RabbitMQ lub Kafka). Serwis wysy\u0142a zadanie do kolejki, nie czeka na odpowied\u017a. Inne serwisy pobieraj\u0105 zadania i przetwarzaj\u0105 w swoim tempie. U\u017cytkownik dostaje potwierdzenie niemal natychmiast, a system jest odporny na przeci\u0105\u017cenia.<\/p>\n Inny spos\u00f3b to zastosowanie wzorca Circuit Breaker i retries z backoffem \u2013 zapobiega to lawinowym b\u0142\u0119dom. Gdy serwis B nie odpowiada, zamiast czeka\u0107 i blokowa\u0107 w\u0105tek, zwracaj szybki b\u0142\u0105d (np. \u201espr\u00f3buj p\u00f3\u017aniej\u201d) i ponawiaj po chwili.<\/p>\n Ka\u017cda sekunda op\u00f3\u017anienia kosztuje. Badania pokazuj\u0105, \u017ce spadek wydajno\u015bci o 1 sekund\u0119 obni\u017ca konwersj\u0119 o 7%. Dla sklepu generuj\u0105cego 10 mln z\u0142 rocznie to 700 tys. z\u0142 straty. A to tylko bezpo\u015brednie koszty. Dochodz\u0105 jeszcze utrata reputacji, gorsze pozycjonowanie w Google (Core Web Vitals), ni\u017csza retencja u\u017cytkownik\u00f3w.<\/p>\n Firmom cz\u0119sto wydaje si\u0119, \u017ce skalowanie to problem \u201ena p\u00f3\u017aniej\u201d. Prawda jest taka, \u017ce lepiej zaprojektowa\u0107 architektur\u0119 od pocz\u0105tku z my\u015bl\u0105 o skali, ni\u017c p\u00f3\u017aniej przepisywa\u0107 wszystko od nowa. Nie oznacza to over-engineeringu \u2013 wystarczy trzyma\u0107 si\u0119 zasad: separacja odpowiedzialno\u015bci, zarz\u0105dzanie stanem, asynchroniczno\u015b\u0107 tam, gdzie to mo\u017cliwe.<\/p>\n Skalowanie to nie tylko kwestia techniczna \u2013 to decyzja biznesowa. Z\u0142e zarz\u0105dzanie stanem, monolit bez podzia\u0142u i synchroniczna komunikacja to trzy pu\u0142apki, kt\u00f3re widz\u0119 najcz\u0119\u015bciej. Ka\u017cda z nich prowadzi do wolniejszej aplikacji, frustracji u\u017cytkownik\u00f3w i utraty pieni\u0119dzy.<\/p>\n Je\u015bli rozpoznajesz kt\u00f3ry\u015b z tych problem\u00f3w u siebie \u2013 nie czekaj. Przyjrzyj si\u0119 architekturze i zastan\u00f3w, czy jest gotowa na wzrost. W JurskiTech pomagamy firmom przeprojektowywa\u0107 aplikacje tak, by skalowa\u0142y si\u0119 bez utraty wydajno\u015bci. Czasem wystarczy zmieni\u0107 kilka nawyk\u00f3w, by zyska\u0107 sekundy i u\u015bmiechy klient\u00f3w.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego wi\u0119kszo\u015b\u0107 firm nie skaluje aplikacji poprawnie? Pami\u0119tam sytuacj\u0119 sprzed dw\u00f3ch lat. Firma e-commerce, kt\u00f3ra ros\u0142a 30% miesi\u0105c do miesi\u0105ca. W pewnym momencie aplikacja zacz\u0119\u0142a zwalnia\u0107 \u2013 czas \u0142adowania wzr\u00f3s\u0142 z 1,5 do 5 sekund. Zesp\u00f3\u0142 w po\u015bpiechu dokupi\u0142 serwery, ale to nie pomog\u0142o. Klienci narzekali, konwersja spad\u0142a o 20 proc. Problemem nie by\u0142a moc<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[34,347,417,309],"class_list":["post-1609","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-oprogramowania","tag-biznes-technologiczny","tag-skalowanie-aplikacji","tag-wydajnosc-it"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1609","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=1609"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1609\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1609"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1609"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1609"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}B\u0142\u0105d #2: Brak zarz\u0105dzania stanem po stronie backendu<\/h2>\n
B\u0142\u0105d #3: Nieoptymalna komunikacja mi\u0119dzy serwisami<\/h2>\n
Jak to przek\u0142ada si\u0119 na biznes?<\/h2>\n
Podsumowanie<\/h2>\n