Паттерны высокого трафика: выбор без самообмана

Для кого: техлиды и системные архитекторы, которых задолбали советы «делайте микросервисы». Если вы уже строите highload, но не знаете, какой паттерн применить и когда — тут будет жёсткая таблица решений.

Провокация №1: вы можете доказать, зачем вам микросервисы?

• Если ответ: «так делают все» — останавливайтесь. Микросервисы = дорого.
• Правило: у вас должно быть хотя бы одно из: независимые команды, разные SLA по доменам, разные темпы обновлений, необходимость изолированного масштабирования.

1. Monolith vs Modular Monolith vs Microservices

Стратегия: начинайте с модульного монолита. Разбивайте модули, если есть фактическая боль.

Провокация №2: у вас есть API gateway? Зачем?

• Gateway — не просто «reverse proxy». Он должен решать auth, rate limiting, observability, кэш.

2. API Gateway vs BFF

Правило: если клиенты сильно отличаются (mobile/web), делайте BFF поверх gateway.

Провокация №3: вы защищены от cascading failure?

• Один медленный сервис может «утопить» всю систему. Circuit breaker и bulkhead должны быть включены по умолчанию.

3. Circuit Breaker

const breaker = new CircuitBreaker(callPaymentService, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 10000,
});

• Открытое состояние = возвращаем fallback/503.
• Метрики: breaker_open_total.

3.1 Bulkhead

• Разделяйте пул потоков/соединений. Пример: отдельный pool для платежей, другой для профиля. Если платежи падают, профиль живёт.

Провокация №4: у вас есть стратегия деградации?

• Если одна функция умирает, что видит пользователь? Вы должны ответить: «мы отключаем рекомендации, но корзина работает».

4. Масштабирование по этапам

Провокация №5: есть ли у вас playbook по переходу?

• Нельзя «просто выделить сервис». Нужен план миграции.

5. Миграция из монолита в сервис

1. Определите bounded context: чёткие границы домена.
2. Стандартизируйте интерфейс: модуль должен иметь public API.
3. Создайте анти-коррупционный слой: слой адаптеров.
4. Вырежьте в отдельный deploy: сначала как модуль (feature flag), потом как сервис.
5. Обеспечьте мониторинг: метрики до/после.

Провокация №6: вы знаете Anti‑Patterns?

• Distributed monolith: сервисы обращаются напрямую к БД друг друга.
• Shared DB: все микросервисы в одной схеме.
• Chatty services: сотни RPC для одного запроса.

Провокация №7: вы документируете архитектуру?

• ADR (Architectural Decision Records) — обязательны. Нельзя «устно» решать.

ADR пример

# ADR-007: Use Kafka for Order Events
Date: 2024-02-01
Context: Need to decouple order processing from notifications.
Decision: Introduce Kafka topic `order-events`, at-least-once delivery.
Consequences: Need idempotent consumers, new team for platform.

Провокация №8: вы проверяете архитектуру тестами?

• Architecture fitness functions: тесты, что сервисы не нарушают правила (e.g., payments не может импортировать orders напрямую).

import { enforceModuleBoundaries } from "@nx/workspace";

Практика

1. ADR:
   • Создайте ADR для выбора между BFF и API Gateway.
2. Circuit breaker:
   • Реализуйте circuit breaker + bulkhead в одном сервисе, симулируйте падение зависимости.
3. Degradation:
   • Напишите документ «если сервис X падает — какие фичи отключаем».
4. Migration plan:
   • Опишите шаги выделения модуля в сервис: data ownership, интерфейсы, тесты.
5. Fitness function:
   • Добавьте тест/линтер, предотвращающий прямой импорт одного модуля в другой.

Что дальше

Вы дошли до финала. Теперь у вас есть набор паттернов, метрик, практик, чтобы масштабировать систему и не сойти с ума. Дальше — только практика и постмортемы.