Mikroserwisy vs monolith — kiedy wybrać co

Każda konferencja tech wygląda tak samo: ktoś pokazuje slajd z mikroserwisami jako rozwiązaniem na wszystkie problemy. Tymczasem wielu doświadczonych inżynierów ostrzega: nie rób mikroserwisów na starcie. **Monolith ma złą reputację której nie zasługuje** Monolityczna architektura: cała aplikacja jako jeden deployment. Prosta w developmencie, łatwa w debugowaniu. Spotify, Shopify, Stack Overflow działały jako monolity przez lata. **Kiedy mikroserwisy mają sens?** - Gdy różne części skalują się niezależnie - Gdy różne zespoły pracują nad różnymi modułami - Gdy moduły wymagają różnych technologii (np. ML w Pythonie, API w Javie) **Co zrobiliśmy w Synaptix?** 8 niezależnych serwisów: GridSense (IoT + Kafka), PredictiveCore (Python ML), AutomateFlow (OCR + NLP), auth-service, api-gateway. Każdy mógł rosnąć w innym kierunku — dlatego separacja miała sens. Najtrudniejsza lekcja: testowanie integracyjne w mikroserwisach jest znacznie trudniejsze. Dead Letter Queue to must-have od dnia pierwszego. **Wniosek:** Zacznij od monolitu. Refaktor do mikroserwisów jest możliwy. Przedwczesna dekompozycja to jeden z największych grzechów inżynierskich.