Rozproszony monolit — jak zdobyć wszystkie wady mikroserwisów i żadnej zalety

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.