Моноліт vs мікросервіси для ML: що обрати на старті

## Хибна дихотомія мікросервісів Серед розробників та архітекторів існує стійкий міф: мікросервіси — сучасно і правильно, моноліт — застаріло і погано. Насправді це помилкова дихотомія, особливо для ML-систем. Правильна відповідь завжди залежить від контексту. Почнемо з визначень. **Монолітна архітектура** для ML-системи означає, що весь код — препроцесінг даних, навчання моделей, API для inference, логування — знаходиться в одному додатку і деплоїться як єдине ціле. **Мікросервісна архітектура** розбиває систему на незалежні сервіси, кожен з яких відповідає за окрему функцію і може деплоїтись незалежно. ## Коли моноліт — правильний вибір **Стартап або ранній MVP.** Якщо ваша ML-система ще знаходиться в стадії доведення гіпотези, моноліт дозволяє рухатись швидко. Немає overhead на міжсервісну комунікацію, немає проблем з distributed tracing, немає необхідності підтримувати кілька репозиторіїв. Один розробник може тримати всю систему в голові. **Одна ML-задача.** Якщо ваш продукт робить одну річ — наприклад, класифікацію вхідних документів — не потрібно розбивати цей процес на мікросервіси. Монолітний Flask або FastAPI-додаток, що приймає документ, класифікує і повертає результат — ідеальне рішення. **Команда до 5 людей.** Мікросервіси вирішують організаційну проблему: як великі команди можуть паралельно розробляти незалежні частини системи. Для маленької команди ця проблема не існує, а overhead від підтримки мікросервісної інфраструктури суттєво сповільнює розробку. **Тісно пов'язані компоненти.** Якщо препроцесінг даних і inference модель завжди виконуються разом і один без одного не має сенсу, поділ на мікросервіси додає складність без реальної вигоди. ## Коли переходити до мікросервісів **Різні вимоги до масштабування.** Якщо ваш inference-сервіс потребує 50 GPU-інстансів, а API-Gateway — 3 CPU-інстанси, моноліт примушує масштабувати все разом. Мікросервіси дозволяють масштабувати кожен компонент незалежно. Це стає важливим при серйозному трафіку. **Кілька незалежних ML-моделей.** Якщо у вас є рекомендаційна система, система детекції шахрайства та модель прогнозування відтоку — кожна з різними вимогами до обчислень, частотою оновлення та командами відповідальності — мікросервіси дозволяють розвивати їх незалежно. **Polyglot persistence та технології.** Рекомендаційна система може потребувати Redis для real-time фіч і Cassandra для historical даних. ML-модель може використовувати TensorFlow Serving, а business logic — Node.js. Мікросервіси дозволяють обирати правильний інструмент для кожної задачі. **Незалежні deployment cycles.** Якщо ви оновлюєте модель кілька разів на тиждень, але бізнес-логіку — раз на місяць, мікросервіси дозволяють деплоїти зміни незалежно без ризику зламати щось суміжне. ## API-патерни для ML-систем Незалежно від архітектури, є кілька перевірених API-патернів для ML: **Synchronous REST** — підходить для inference з низькою латентністю (менше 500 мс). Простий у реалізації, легко відлагоджується. FastAPI + Pydantic — стандарт де-факто в Python-екосистемі. **Async/Queue-based** — для важких обчислень (навчання, batch inference). Запит ставиться в чергу (Redis, RabbitMQ, Celery), результат отримується пізніше через polling або webhook. Підходить для задач, де результат потрібен не миттєво. **Streaming** (gRPC Streaming, WebSocket) — для задач, де результат генерується поступово (LLM generation, video processing). Складніший в реалізації, але дає кращий UX для тривалих обчислень. **Практична рекомендація:** починайте з монолітного FastAPI-додатку. Виносьте в окремий сервіс лише тоді, коли є конкретна причина: різні вимоги до масштабування, різні команди або несумісні технологічні стеки. Передчасна мікросервісна архітектура — одна з найдорожчих помилок в ML-розробці.