До нас приходить власник інтернет-магазину: сайт на єдиній кодовій базі, кожен реліз зачіпає весь застосунок, а нова інтеграція з Nova Poshta ламає оформлення замовлення. Питання, яке він ставить, звучить просто: «Треба все переписати на мікросервіси?» Наша відповідь майже завжди складніша за «так» або «ні».
Моноліт — це один застосунок, де вся логіка живе разом і деплоїться цілком. Модульна архітектура розбиває систему на окремі частини з чіткими межами: каталог, оплата, доставка, обліковий шар спілкуються через контракти. Обидва підходи робочі. Різниця в тому, яку ціну ви платите за зміни й за масштаб.
Як ми ухвалюємо рішення
Ми не обираємо архітектуру під моду. Ми дивимось на конкретні сигнали бізнесу й команди:
- Розмір і темп команди. Одна команда з чотирьох розробників швидше рухається на добре структурованому моноліті, ніж на десятку сервісів.
- Профіль навантаження. Якщо пікове навантаження б'є в одну частину — наприклад, у пошук чи чекаут, — має сенс винести саме її.
- Складність інтеграцій. Платежі LiqPay і Monobank, доставка, обліковий шар — коли їх багато й вони змінюються незалежно, модульні межі окупаються.
- Швидкість релізів. Якщо кожна дрібна правка вимагає повного регресу — це сигнал, що межі всередині коду розмиті.
Для більшості проєктів ми стартуємо з модульного моноліту: один деплой, але з ясними внутрішніми межами між доменами. Це дає дисципліну сервісів без операційних витрат на розподілену систему.
Що це виглядає на практиці
Беремо той самий магазин на Laravel. Замість того щоб дробити його на сервіси, ми виділяємо домени в межах одного застосунку: сервісний шар для замовлень, окремий модуль інтеграцій із доставкою, ізольований платіжний шар з ідемпотентною обробкою вебхуків. Кожен модуль має власний контракт, тож зміна в доставці більше не чіпає чекаут.
Коли конкретний домен справді впирається в стелю — наприклад, обробка платіжних вебхуків під пікові розпродажі, — ми виносимо його в окремий сервіс уже за готовою межею. Розділення стає інженерним рішенням на даних, а не ставкою навмання.
Результат для бізнесу
Такий підхід дає передбачувані релізи: правка в одному домені не тягне за собою повний регрес усього сайту. Команда виносить у прод швидше, бо тестує вужчу зону. А коли бізнес доростає до реального навантаження, міграція окремого модуля в сервіс займає дні, а не квартал переписування з нуля. Ви платите за складність розподіленої системи тоді, коли вона справді потрібна, — і не раніше.
Якщо ваш застосунок став важким на кожен реліз, почніть не з переписування, а з аудиту меж. Ми проходимо код, визначаємо домени й показуємо, що варто виносити, а що краще лишити разом.