Защита от «грома»

1. Rate limiter. Ограничить количество исходящих запросов в секунду (token bucket).
2. Circuit breaker. При N неудачах подряд — перестать слать запросы на cooldown период.
3. Backoff с jitter. При retry — экспоненциальный backoff + случайный jitter.
4. Кэширование ответов. Если данные не критичны, кэшировать на N минут.
5. Bulkheading. Изолировать пулы соединений для разных внешних API.
6. Timeout на каждый вызов. Не ждать бесконечно.

Внешний вызов — это side effect. Никогда не вызывайте внешние API во время reprocessing. Если событие требует внешнего вызова — используйте паттерн обработки с outbox: сначала сохранить команду, потом асинхронно выполнить вызов.

VICQRS и обслуживание запросов

Если данные живут в потоках событий, как нам быстро отдать их фронтенду по REST-запросу? Ответ — CQRS (Command Query Responsibility Segregation): команды пишут через event stream, запросы читают из read model.

Ключевое: read model — это проекция, а не реплика. Данные не просто копируются — они фильтруются, агрегируются и пересчитываются под нужды конкретного потребителя.

// Read model для запроса «заказы клиента»
CREATE TABLE customer_orders_read_model (
    customer_id UUID,
    order_id UUID,
    status VARCHAR(50),
    total_amount DECIMAL(10,2),
    created_at TIMESTAMP,
    PRIMARY KEY (customer_id, created_at)
);

// Обновляется асинхронно из потока OrderEvents
// Не является источником истины
// Оптимизирован под запрос "покажи все заказы клиента X"

VIIТри подхода к материализации состояния

VIIIAPI Gateway и BFF

API Gateway — это не только routing. Это edge service, который объединяет данные из нескольких микросервисов для конкретного клиента.

Backend for Frontend (BFF)

Один API Gateway не подходит для всех. Мобильный клиент и веб-клиент имеют разные потребности:

• Mobile BFF — минимум данных, агрессивное кэширование, медленные сети.
• Web BFF — больше данных, меньшая задержка, шире payload.
• Public API BFF — версионирование, документация, rate limits.

IXЗапросы как события: смена парадигмы UI

Самый радикальный подход — вообще отказаться от прямого изменения БД по REST-запросу. Когда пользователь нажимает «Оформить заказ», API не пишет в БД. Он создаёт команду PlaceOrder и отправляет её в поток.

Это гарантирует, что каждое действие пользователя становится частью неизменяемого журнала. Но как быть с интерфейсом? Пользователи не привыкли ждать.

XEventual consistency на клиенте

Клиент отправил команду → она обрабатывается асинхронно → состояние материализуется. Это может занять секунды. Как UI должен работать с этим?

Пример: SSE для обновления статуса заказа

// Client
const eventSource = new EventSource(`/orders/${orderId}/stream`);

eventSource.addEventListener("status", (event) => {
    const data = JSON.parse(event.data);
    updateOrderStatus(data.status);
});

// Server (Spring WebFlux)
@GetMapping(value = "/orders/{orderId}/stream", produces = TEXT_EVENT_STREAM_VALUE)
public Flux<OrderStatus> streamOrderStatus(@PathVariable String orderId) {
    return kafkaStreams
        .stream("order-events")
        .filter((key, event) -> event.getOrderId().equals(orderId))
        .map(this::toOrderStatus);
}

XIЧеловеческий фактор: паттерн одобрения

Что делать, если бизнес-процесс требует участия человека? Классический пример — вёрстка газеты или модерация контента. Дизайнер готовит макет, редактор одобряет, рекламодатель согласовывает баннеры.

В событийной архитектуре каждый шаг — это не обновление строки в БД, а публикация нового события (LayoutApprovedByEditor, AdRejectedByAdvertiser). Это позволяет:

• «Отмотать» историю согласований — кто и когда заблокировал процесс.
• Построить прозрачный аудит без сложных таблиц статусов.
• Интегрировать human-in-the-loop с Saga (глава VIII) — через wait-for-signal в Temporal или Durable Functions.

XIIМикрофронтенды: зеркальное отражение бэкенда

Если ваш бэкенд разбит на независимые bounded contexts (микросервисы), то и монолитный фронтенд станет узким местом. Здесь на сцену выходят микрофронтенды — прямая реализация закона Конвея (глава I) на уровне UI.

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

Плюсы и минусы композиции

Четыре подхода к композиции

XIIIContract testing: API и events не должны расходиться

Когда API генерирует команды и события, контракт между API и event schema должен быть протестирован. Иначе API изменится, а схема останется старой — или наоборот.

Три подхода к contract testing

1. Consumer-driven contracts (Pact). Потребитель описывает ожидания, продюсер проверяет их в CI. Прямая связь с главой III (Schema Registry).
2. Schema validation в CI. API Gateway валидирует команды против JSON Schema перед публикацией в Kafka. Schema Registry валидирует события против Avro/Protobuf.
3. Integration tests через Testcontainers. Полный pipeline: API → Command → Event → Read model.

XIVЧеклисты и связь с циклом

Связь с предыдущими главами

Чеклист проектирования API-границы

• API принимает Command, не публикует «событие»
• Ответ — 202 Accepted с ID для отслеживания
• Idempotency-Key в заголовке (генерируется клиентом)
• Idempotency окно ≥ retry-окно клиента (обычно 24–72 часа)
• Аутентификация: OAuth 2.0 / JWT / mTLS
• Авторизация: RBAC / ABAC / scope-based
• Rate limiting per user / per API key
• WAF перед API Gateway
• Input validation через JSON Schema / Protobuf
• External API calls — только через outbox, не в reprocessing
• Rate limiter + circuit breaker для внешних API
• CQRS: команды через stream, запросы из read model
• Read model — проекция, не реплика
• API Gateway / BFF для композиции данных
• Eventual consistency на клиенте: optimistic UI / SSE / WebSocket
• Contract testing в CI (Pact / schema validation)
• Микрофронтенды по bounded contexts, с Design System

Ключевые выводы главы

1. Command vs Event vs Query. API принимает команды, публикует события, отдаёт данные через query.
2. 202 Accepted вместо 200 OK — клиент понимает асинхронность.
3. Idempotency-Key защищает от повторов при retry.
4. Security на границе — auth, авторизация, rate limit, WAF, validation.
5. Внешние API — через outbox. Никогда не вызывать внешние API в reprocessing.
6. CQRS — команды через stream, запросы из read model.
7. Три подхода к материализации: embedded, external, разделённые сервисы.
8. API Gateway / BFF — композиция данных для конкретного клиента.
9. Запросы как события — радикальная смена парадигмы UI.
10. Eventual consistency на клиенте — optimistic UI, polling, SSE, WebSocket.
11. Паттерн одобрения — human-in-the-loop через события.
12. Микрофронтенды — зеркальное отражение bounded contexts.
13. Contract testing — API и events не должны расходиться.

Глава XIII цикла «Событийно-управляемая архитектура». Источники: Apache Kafka, Confluent, Microservices.io, Pact, Temporal, AWS Architecture Center, практические кейсы production-систем, FinCodeCow experience.