Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Що таке «Distributed Monolith»?». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

**Distributed Monolith** («розподілений моноліт») - це антипатерн, за якого система зовні виглядає як набір мікросервісів, але фактично поводиться **як єдиний моноліт**.

### Суть

Сервіси формально розділені, але мають жорсткі залежності:

- вимагають одночасного деплою,
- сильно пов'язані API-викликами,
- не можуть працювати незалежно.

*По суті:* система отримала складність розподіленості, мережі, DevOps, оркестрацію, але не отримала переваг мікросервісів: автономності і гнучкості.

### Ознаки «distributed monolith»

1. **Сервіси не можуть розгортатися окремо:** зміна одного вимагає перекомпіляції інших.
2. **Забагато синхронних викликів:** кожен запит «чіпляє» ланцюжок із 5-10 сервісів.
3. **Спільні бібліотеки або БД:** зміна схеми ламає все.
4. **Немає незалежного версіювання:** усе релізиться «одним великим комітом».
5. **Часті каскадні помилки:** падіння одного сервісу валить усю систему.

### Чому це погано

- Втрата незалежності і масштабованості.
- Релізи і тестування стають складнішими, ніж у монолiту.
- Система перевантажена мережевими викликами і DevOps-складністю без вигоди.

### Як уникнути

- Розділяти сервіси за **bounded context**.
- Використовувати **асинхронну комунікацію** і **чіткі API-контракти**.
- Ізолювати дані і релізи.
- Впроваджувати **тести контрактів** між сервісами.

**Підсумок:**

> **Distributed Monolith** - це «моноліт, розрізаний мережею».
> Він складний, крихкий і втрачає сенс мікросервісної архітектури.
> Головна ознака - залежність між сервісами сильніша, ніж їхня автономність.

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати197 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.