← Назад в блог

Монолит или микросервисы — как выбрать архитектуру для стартапа в 2026 году

монолит или микросервисыmonolith vs microservices стартапкогда использовать микросервисымодульный монолитархитектура стартапаmicroservices для малой командымонолит инди хакервыбор архитектуры приложения

Для стартапа, инди-хакера или небольшой команды ответ однозначный: начинайте с монолита. Микросервисы — это решение для проблем большого масштаба, которых у вас ещё нет. Разберём почему, и когда это правило стоит нарушить.

Что такое монолит и что такое микросервисы

Монолит

Монолитное приложение — это единый деплоируемый юнит. Вся бизнес-логика, API, фоновые задачи и UI (если есть) живут в одном кодовом репозитории и деплоятся вместе.

myapp/
├── api/
│   ├── users.py
│   ├── products.py
│   └── orders.py
├── services/
│   ├── email_service.py
│   └── payment_service.py
├── models/
│   ├── user.py
│   ├── product.py
│   └── order.py
├── workers/
│   └── background_tasks.py
└── main.py

Один процесс, одна база данных, один деплой.

Микросервисы

Микросервисная архитектура — это набор независимых, слабо связанных сервисов, каждый из которых:

  • Имеет свою базу данных
  • Деплоится независимо
  • Общается с другими через API или message broker (RabbitMQ, Kafka)
  • Разрабатывается и масштабируется независимо
services/
├── user-service/          # Python FastAPI, PostgreSQL
├── product-service/       # Go, MongoDB
├── order-service/         # Java, MySQL
├── notification-service/  # Node.js, Redis
└── api-gateway/           # Nginx + routing

Почему стартапу нужен монолит

Аргумент 1: Скорость разработки — это ваш главный актив

На ранней стадии стартапа главная задача — найти Product-Market Fit. Это требует быстрых итераций: запустили фичу, получили фидбек, изменили, запустили снова.

В монолите изменение функции заказов затрагивает один файл и один деплой. В микросервисах — нужно изменить API-контракт, обновить order-service, обновить api-gateway, проверить совместимость с product-service, синхронизировать версии.

Аргумент 2: Инфраструктура микросервисов стоит дорого

Исследования показывают: инфраструктура для микросервисов обходится в 3.75-6 раз дороже монолита при сопоставимой нагрузке. Для стартапа это прямые деньги из бюджета.

Что нужно для микросервисов:

  • Kubernetes или аналог (оркестрация)
  • Service Mesh (Istio, Linkerd) для коммуникации
  • Распределённое логирование (ELK Stack или Loki)
  • Distributed tracing (Jaeger, Zipkin)
  • API Gateway
  • Message Broker (Kafka, RabbitMQ)
  • Отдельные CI/CD пайплайны для каждого сервиса
  • DevOps-инженер, который всё это поддерживает

Всё это — до того, как у вас появился первый платный пользователь.

Аргумент 3: Распределённые системы — это сложно

В монолите: вызвать функцию = 0мс, всегда успешно. В микросервисах: HTTP-запрос к другому сервису = 1-10мс, может упасть, может timeout, может вернуть устаревшие данные.

Проблемы, которые появляются только в микросервисах:

  • Частичный отказ (один сервис упал, другие работают)
  • Распределённые транзакции (как отменить заказ, если payment-service упал после списания?)
  • Eventual consistency (данные в разных сервисах могут быть рассинхронизированы)
  • Версионирование API между сервисами
  • Дедлоки через network calls

Аргумент 4: 42% компаний возвращаются к монолитам

По данным CNCF, около 42% компаний, начавших с микросервисов, в итоге вернулись к монолитам или модульным монолитам. Amazon, Netflix, Uber — они перешли на микросервисы имея тысячи инженеров, не сотни пользователей.

Модульный монолит: лучшее из двух миров

Модульный монолит — это монолит с чёткими внутренними границами между компонентами. Он даёт скорость монолита и готовность к декомпозиции при необходимости.

Как выглядит модульный монолит

# Модуль Users
# users/models.py, users/service.py, users/api.py

# Модуль Orders
# orders/models.py, orders/service.py, orders/api.py

# Модули НЕ обращаются напрямую к моделям друг друга
# Только через публичные интерфейсы (service functions)

# ПЛОХО: прямой доступ к модели другого модуля
from orders.models import Order  # из users/

# ХОРОШО: через сервисный слой
from orders.service import get_user_orders  # Публичный API модуля

Пример структуры на FastAPI

# app/modules/users/
#   models.py     — User SQLModel
#   service.py    — create_user, get_user, update_user
#   api.py        — FastAPI router
#   events.py     — события (UserCreated, UserUpdated)

# app/modules/orders/
#   models.py     — Order SQLModel
#   service.py    — create_order, cancel_order
#   api.py        — FastAPI router
#   events.py     — OrderCreated, OrderCancelled

# app/modules/payments/
#   service.py    — process_payment, refund
#   api.py

# main.py — собираем всё вместе
from app.modules.users.api import router as users_router
from app.modules.orders.api import router as orders_router
from app.modules.payments.api import router as payments_router

app = FastAPI()
app.include_router(users_router, prefix="/users")
app.include_router(orders_router, prefix="/orders")
app.include_router(payments_router, prefix="/payments")

Такая архитектура: один деплой, одна БД, но чёткие границы. Когда вырастете — «отпилить» payments в отдельный сервис будет несложно.

Когда переходить на микросервисы

Реальные триггеры, а не теоретические:

Триггер 1: Команда мешает друг другу

Когда 3+ команды работают над одним репозиторием и постоянно конфликтуют при мерджах, тормозят деплой друг друга — это сигнал. Обычно это происходит при 20-50+ инженерах.

Триггер 2: Один компонент убивает всё

Например, тяжёлые вычисления (ML-обработка, конвертация видео) потребляют весь CPU и роняют API. Этот компонент стоит выделить в отдельный сервис с независимым масштабированием.

API (5 инстансов, 1 CPU) + Video Processing (2 инстанса, 16 CPU)
vs.
Монолит (7 инстансов, 17 CPU каждый) — неэффективно

Триггер 3: Разные технические требования

Если часть системы должна быть на Python (ML), часть на Go (high-performance API), часть на Node.js (real-time WebSocket) — микросервисы позволяют использовать правильный инструмент для каждой задачи.

Триггер 4: Изоляция критичных данных

Платёжные данные требуют PCI DSS compliance? Медицинские данные требуют HIPAA? Выделение в отдельный сервис упрощает аудит и compliance.

Практическое сравнение

| Критерий | Монолит | Микросервисы | |---|---|---| | Скорость разработки | Высокая | Низкая (особенно начало) | | Сложность деплоя | Низкая (один деплой) | Высокая (N деплоев) | | Отладка | Простая (один лог) | Сложная (distributed tracing) | | Стоимость инфраструктуры | Низкая | В 3-6 раз выше | | Масштабирование | Вертикальное / горизонтальное всего | Независимое для каждого сервиса | | Команда | 1-15 человек | 20+ человек | | Транзакции | ACID через ORM | Сложные (saga, two-phase commit) | | Время до первого деплоя | Минуты | Дни-недели | | Подходит для | Стартапы, MVP, инди-хакеры | Крупные компании, после PMF |

Реальные примеры

Истории успеха монолитов

  • Basecamp — один из самых прибыльных SaaS на Rails, до сих пор монолит
  • GitHub — долго был монолитом (Rails), перешёл на частичную декомпозицию только после многих лет
  • Shopify — модульный монолит на Rails, 100M+ запросов в день
  • Stack Overflow — один сервер долгое время обслуживал миллионы запросов

Когда микросервисы оправданы

  • Netflix — 1000+ микросервисов, сотни инженеров, уникальные требования к масштабированию
  • Amazon — декомпозиция по командам («pizza team»)
  • Uber — географически распределённые операции с разными требованиями

Заметьте: все эти компании начали как монолиты.

Micro-SaaS: особый случай

Micro-SaaS — это маленький SaaS-продукт, решающий узкую задачу для нишевой аудитории. Обычно делается одним человеком (солопринером) или маленькой командой.

Для micro-SaaS ответ ещё более однозначен: монолит, и желательно максимально простой.

Идеальный стек для micro-SaaS в 2026:

  • Django + PostgreSQL (или FastAPI + SQLModel)
  • SQLite для начала (быстрый старт, одна команда деплоя)
  • Railway или Render для хостинга (без DevOps)
  • Stripe для платежей

Никаких Kubernetes, никакого Kafka, никаких микросервисов.

Когда начать думать о декомпозиции

Признаки, что монолит начинает мешать:

  • Сборка и тесты занимают больше 10-15 минут
  • Деплой занимает больше 30 минут
  • Добавление новой фичи требует изменений в 10+ файлах
  • Разные части системы имеют конфликтующие зависимости
  • Один компонент регулярно роняет весь сервис

Первый шаг — не микросервисы, а модульный монолит с чёткими границами.

Бэкапы в монолите: проще, чем в микросервисах

Одно из неочевидных преимуществ монолита — простота резервного копирования. Одна база данных — один бэкап. В микросервисах у каждого сервиса своя БД, бэкапить нужно каждую, синхронизировать восстановление между ними.

Для монолита с PostgreSQL или SQLite бэкап настраивается через dbsend.ru за пять минут: один токен, расписание, и бэкап уходит в облако. Никаких дополнительных инструментов.

FAQ

Что делать, если я уже начал с микросервисов? Не паникуйте. Если система ещё маленькая — рассмотрите консолидацию: объедините связанные сервисы в один. Это называется «strangler fig в обратную сторону». Если уже в продакшене с реальной нагрузкой — оцените, действительно ли декомпозиция приносит проблемы. Иногда работающая система лучше идеальной.

Монолит — это всегда спагетти-код? Нет. Монолит может быть хорошо структурированным. Модульный монолит с чёткими границами между модулями — это не спагетти. Спагетти-код — это проблема дисциплины, а не архитектуры.

Можно ли начать с монолита и потом перейти на микросервисы? Да, и это стандартный путь. Ключ — проектировать монолит с чёткими модульными границами с самого начала. «Отпилить» хорошо изолированный модуль несложно. Распутать настоящее спагетти — задача на месяцы.

Serverless — это микросервисы? Serverless (AWS Lambda, Yandex Functions) — это функции-сервисы. Концептуально близко к микросервисам, но ещё более атомарно. Для стартапа serverless может быть хорошим выбором для конкретных задач (обработка файлов, webhook-и), но полностью serverless-монолит (через SST, Serverless Framework) имеет свои сложности.

Netflix на микросервисах — значит, это правильный путь? Netflix перешёл на микросервисы имея миллионы пользователей, сотни инженеров и уникальные требования к надёжности (они стримят видео 24/7 по всему миру). Ваш стартап с 100 пользователями — это другой контекст.

Когда микросервисы оправданы для небольшой команды? Если у вас есть компонент с принципиально разными требованиями: например, ML-модель для обработки данных (Python, GPU) и основное API (Go, низкая латентность). Или если нужна изоляция для compliance (PCI DSS, HIPAA). Но это исключение, не правило.