Architektura monolityczna (ang. monolithic architecture) to model budowy aplikacji, w którym cały kod — interfejs użytkownika, logika biznesowa i warstwa dostępu do danych — żyje w jednym projekcie, kompiluje się do jednego artefaktu i wdraża jako jeden proces. Jeden deploy, jedna baza kodu, jeden uruchomiony program. Nie ma tu osobnych usług gadających po sieci, jest za to jeden duży blok, który albo działa w całości, albo nie działa wcale.
Jak to działa
Wszystkie moduły wywołują się nawzajem zwykłymi metodami w ramach jednego procesu — bez HTTP, bez kolejek, bez serializacji. Dzięki temu monolit jest szybki w komunikacji wewnętrznej i prosty w debugowaniu: masz jeden stack trace, jedne logi, jeden punkt wejścia. Skalowanie odbywa się zwykle horyzontalnie — uruchamiasz kilka kopii tej samej aplikacji za load balancerem.
To świetny wybór na start: dla MVP, małego zespołu albo gdy domena nie jest jeszcze poukładana. Mniej ruchomych części znaczy mniej rzeczy, które mogą się zepsuć w nocy. Problemy zaczynają się przy wzroście — kod się rozrasta, granice między modułami się rozmywają, a każda drobna zmiana wymaga przebudowy i redeploya całości.
Przykład z praktyki
Klasyczny monolit to aplikacja Spring Boot albo Django spakowana w jeden artefakt. W Springu robisz mvn package, dostajesz pojedynczy plik app.jar i odpalasz całość komendą java -jar app.jar. Kontrolery, serwisy, repozytoria — wszystko w jednym JAR-ze, jedno połączenie do bazy. Chcesz obsłużyć większy ruch? Stawiasz trzy instancje tego samego JAR-a w Dockerze i wpinasz je pod nginx jako upstream. Nie musisz rozbijać systemu na mikroserwisy, żeby udźwignąć rozsądne obciążenie.
Częste mity
„Monolit to przeżytek” — nieprawda. Dla większości projektów to rozsądny domyślny wybór, a przedwczesne dzielenie na mikroserwisy potrafi pogrzebać startup szybciej niż brak klientów. „Monolit nie skaluje się” — skaluje, tylko w całości: jeśli wąskim gardłem jest jeden moduł, i tak musisz mnożyć całą aplikację, co bywa marnotrawstwem zasobów. Realne pułapki to tight coupling (moduły wrastają w siebie), długie czasy buildu i to, że jeden feralny deploy kładzie cały system. Warto trzymać czyste granice modułów wewnątrz monolitu — wtedy ewentualny rozkład na usługi będzie operacją chirurgiczną, a nie amputacją.
Pojęcia powiązane
Mikroserwisy (microservices), modular monolith, SOA, API gateway, CI/CD, monorepo, tight coupling, bounded context.