Kiedy monolit jest właściwą odpowiedzią
Rozbijanie aplikacji na mikroserwisy zanim to konieczne to najczęstszy błąd architektoniczny we wczesnych projektach. Ten artykuł wyjaśnia dlaczego.
Mit "mikroserwisów od początku"
Zespoly często zaczynają od decyzji: "zróbmy to jako mikroserwisy, żeby było skalowalne". Problem polega na tym, że skalowalność rzadko jest tym, czego projekt potrzebuje na starcie. Zamiast tego dostajesz:
- rozproszoną złożoność (sieć wywołań, tracing, retries),
- koszt transakcyjności (distributed transactions to bolączka),
- trudniejsze debugowanie (logi w 12 serwisach),
- wyzszy próg wejścia dla nowych ludzi.
Monolit nie jest "złym słowem"
Dobrze zaprojektowany monolit (modular monolith) daje:
- Jednę bazę danych — transakcyjność za darmo.
- Proste wdrażanie — jeden artefakt.
- Łatwe refactoring — zmiana interfejsu między modułami to zmiana w tym samym repo.
Kluczem jest modularność wewnątrz monolitu: wyraźne granice modułów, jawne zależności, brak współdzielonego stanu globalnego.
Kiedy naprawdę przejść na mikroserwisy
Rozważ podział gdy:
- masz odrębne profile skalowania (API ma inny ruch niż worker analizy),
- niezależne zespoły muszą wdrażać niezależnie,
- pojedynczy język/techstack staje się wąskim gardłem,
- wymagasz izolacji awarii (bład w module X nie kładzie Y).
Trade-offy o których się nie mówi
Mikroserwisy wymieniają "złożoność kodu" na "złożoność operacyjną". To nie znika — przenosi się na infrastrukturę, monitoring i on-call. Jeśli nie masz nikogo, kto utrzyma tę infrastrukturę, monolit jest uczciwszym wyborem.
Podsumowanie
Zacznij od modularnego monolitu. Wydzielaj serwisy tylko wokół rzeczywistych granic biznesowych i operacyjnych — nie hipotetycznej skalowalności. "Mikroserwisy od początku" to najczęściej przedwczesna optymalizacja ubrana w modne słowo.