Scenariusz dydaktyczny złożony z typowych błędów. Nie opisuje jednej konkretnej organizacji ani potwierdzonego incydentu.
Punkt wyjścia
Dojrzały monolit obsługiwał e-commerce średniej wielkości. Działał, ale zespół czuł, że „urósł” — wdrożenia były stresujące, a modne konferencje mówiły jedno: mikroserwisy. Padła decyzja: rozbijamy na kilkanaście serwisów, bo „mikroserwisy się skalują i pozwalają zespołom pracować niezależnie”.
Co zrobili
- Podzielili system wg warstw i encji technicznych: osobny serwis do użytkowników, osobny do zamówień, do koszyka, do cen, do powiadomień… kilkanaście sztuk.
- Serwisy wołały się synchronicznie, w łańcuchu: jedno żądanie użytkownika przechodziło przez A → B → C → D, każdy czekał na następny.
- Wszystkie serwisy współdzieliły jedną bazę danych — „przecież dane i tak są wspólne”.
- Zmiana w jednym serwisie zwykle wymuszała skoordynowaną zmianę w kilku innych, więc i tak deployowali wszystko razem.
Dlaczego taki układ może się posypać
- Latencja się sumowała. Żądanie, które w monolicie było jednym wywołaniem w pamięci, teraz przechodziło przez cztery skoki sieciowe. Wolniej i mniej przewidywalnie.
- Zero izolacji awarii. Gdy jeden serwis w łańcuchu zwalniał albo padał, kładł całe żądanie. Zamiast „jedna funkcja niedostępna” mieli „sklep nie działa”. Do tego kaskadowe awarie: przeciążony serwis pociągał za sobą tych, którzy na niego czekali.
- Współdzielona baza = ukryte sprzężenie. Każda zmiana schematu mogła niepostrzeżenie zepsuć inny serwis. Niezależność była pozorna.
- Brak niezależnego wdrażania. Skoro zmiany i tak trzeba było koordynować, stracili największą obiecywaną zaletę mikroserwisów — a zostały im wszystkie koszty: sieć, obserwowalność, złożoność operacyjna, debugging rozłażący się przez kilkanaście usług.
Krótko: dostali wady monolitu (sprzężenie) plus wady rozproszenia (sieć i złożoność). Najgorszy z obu światów.
Jak to było widać z wyprzedzeniem
Podczas przeglądu warto zadać pytania:
- Czy te serwisy mogą się zmieniać i wdrażać niezależnie? (Jeśli nie — to nie są osobne serwisy, tylko jeden system pocięty na kawałki.)
- Co się stanie, gdy jeden z nich padnie? (Jeśli odpowiedź brzmi „padnie całość” — nie ma izolacji, czyli nie ma korzyści.)
- Dlaczego dzielą jedną bazę? (Współdzielona baza to najczęstszy objaw fałszywych granic.)
- Wg czego wytyczono granice — wg domeny i własności danych, czy wg warstw technicznych?
Granice wyznaczono technicznie (użytkownicy, zamówienia, ceny jako osobne pudełka), a nie wg domeny i własności danych. To jest źródło całego nieszczęścia.
Lekcja (przenośna reguła)
Mikroserwisy to strategia organizacyjna, nie techniczna moda. Ich sens to niezależne zespoły, niezależne wdrożenia i izolacja awarii. Jeśli serwisy muszą się zmieniać razem i dzielą dane, to jest jeden system pocięty na kawałki — gorszy niż monolit, bo do sprzężenia dokłada sieć.
Co z tego wynika w praktyce:
- Zacznij od modularnego monolitu. Wydzielaj serwis dopiero, gdy masz realny powód: niezależne skalowanie albo osobny zespół z własnym cyklem wdrożeń.
- Granice wg domeny i własności danych, nie wg warstw. Jeden serwis = jedna baza; nikt inny do niej nie sięga.
- Komunikacja asynchroniczna tam, gdzie chcesz izolacji awarii — żeby padnięcie jednego nie kładło całego łańcucha.
Rozbicie na serwisy to nie cel. Celem jest niezależność. Jeśli jej nie zyskujesz — nie rozbijaj.