Архитектурный challenge: E-commerce Streaming

Это упражнение на проектирование архитектурного документа. Вам не нужен запущенный кластер Kafka. Ваш результат — архитектурный документ, описывающий решение.

Контекст задачи

Вы — ведущий data-инженер крупного интернет-магазина. Компания переходит с монолитной архитектуры на микросервисы и требует построить стриминговую платформу, которая станет основой всей операционной деятельности.

Функциональные требования

Ваша архитектура должна обеспечить следующие сценарии:

1. Order Service публикует события заказа: created, updated, confirmed, cancelled
2. Payment Service обрабатывает платежи асинхронно по событию создания заказа
3. Inventory Service резервирует и освобождает складские остатки после подтверждения платежа
4. Notification Service отправляет email/SMS подтверждения клиентам
5. Аналитическая команда требует real-time дашборды: заказы в минуту, выручка, топ-продукты
6. Команда поиска требует near-real-time обновления каталога продуктов в Elasticsearch
7. Финансовая команда требует ежедневные отчёты сверки из PostgreSQL

Нефункциональные требования

Это ограничения, которые определяют технические решения:

Структура архитектурного документа

Ваш документ должен содержать шесть разделов. Ниже — детальные инструкции по каждому.

Раздел 1: Каталог топиков

Что включить:

Для каждого топика укажите:

• Полное имя топика (следуя соглашению {domain}.{entity}.{event-type} из Модуля 12)
• Количество партиций с обоснованием (от пропускной способности или числа consumers)
• Политику retention и cleanup
• Avro-схему (минимальные поля: id, timestamp, key)
• Владелец (consumer group или сервис)

Подсказки для расчёта партиций:

При 10 000 заказов/сек и допущении 1 000 сообщений/сек на партицию (при 1 KB сообщениях и Kafka max throughput ~10 MB/s per partition):

Минимальное число партиций = ceil(пиковый_throughput / throughput_per_partition)
= ceil(10 000 / 1 000) = 10
Округляем до кратного числу брокеров: 12 партиций

Какие топики создать (минимальный список):

• orders.order.created — события создания заказов
• orders.order.confirmed — подтверждённые заказы
• orders.order.cancelled — отменённые заказы
• payments.payment.charged — успешные списания
• payments.payment.refunded — возвраты
• inventory.item.reserved — резервирование товара
• orders.order.enriched — обогащённые заказы (output Kafka Streams)
• saga.order-fulfillment.state — состояние саги выполнения заказа

Ссылки на курс: Модуль 06 (Schema Registry, Subject naming strategy), Модуль 12 (Topic Governance, naming conventions)

Раздел 2: Архитектура сервисов

Что включить:

Для каждого из 5 микросервисов:

• Какие топики читает (с именем consumer group)
• Какие топики пишет
• Стратегия идемпотентности (dedup по ключу, enable.idempotence=true, или transactional producer)
• Какой паттерн из Модуля 12 применяется: Event Sourcing, CQRS, Outbox, или Saga?

Ключевые решения:

Order Service: Использует ли event sourcing для агрегата заказа? Как гарантирует надёжную публикацию в Kafka при сбое (transactional outbox)?

Payment Service: Как достигается exactly-once? Idempotent consumer + dedup по orderId? Или Kafka транзакции с transactional.id? Обоснуйте выбор.

Saga: При 4+ сервисах в цепочке выполнения заказа — хореография или оркестрация? Запишите своё решение и аргументы. Какие компенсирующие транзакции нужны при сбое на шаге 3 (резервирование инвентаря)?

Ссылки на курс: Модуль 02-03 (Producers/Consumers, API), Модуль 12 (Design Patterns: Event Sourcing, Outbox, Saga)

Раздел 3: Стриминговый конвейер

Что включить:

Kafka Streams topology:

• Исходный топик(и)
• KTable (какие данные, ключ)
• JOIN или агрегация
• Выходной топик
• Используйте псевдокод topology (не обязателен компилируемый код)

Kafka Connect pipeline:

• JDBC Sink: из какого топика, в какую таблицу PostgreSQL, batch size, poll interval
• Elasticsearch Sink: из какого топика, в какой индекс, как формируется document id

Ссылки на курс: Модуль 05 (Kafka Connect, JDBC/Elasticsearch Sinks), Модуль 07 (Kafka Streams DSL, KTable JOIN)

Раздел 4: Дизайн безопасности

Что включить:

SASL/SCRAM-SHA-256: Каждый сервис имеет уникальные credentials. Перечислите principals.

ACL матрица (минимум):

Ссылки на курс: Модуль 09 (Security: SASL/SCRAM, ACL, StandardAuthorizer)

Раздел 5: Multi-DC и Disaster Recovery

Что включить:

MirrorMaker 2 topology:

• Выбор: active-passive или active-active? Для данного сценария e-commerce (один основной DC, один DR) рекомендуется active-passive.
• Какие топики реплицировать?
• DefaultReplicationPolicy или IdentityReplicationPolicy? Обоснуйте.
• sync.group.offsets.enabled и его значение для автоматического failover.

RPO/RTO анализ:

Запишите конкретные цифры:

• RPO = задержка репликации MM2 (типично 2–5 секунд при правильной конфигурации, значительно меньше 30-секундного требования)
• RTO = сумма компонентов: обнаружение сбоя + failover DNS + перевод offset + перезапуск сервисов

Runbook failover (нумерованные шаги):

1. Мониторинг фиксирует недоступность DC-1
2. Остановка producers, направленных на DC-1
3. Ожидание дренирования MM2 лага (или принятие текущего RPO)
4. Проверка офсетов на DC-2 (автоматически через sync.group.offsets.enabled=true)
5. Обновление DNS / load balancer на DC-2
6. Запуск consumers на DC-2 (читают dc1.{topic} при DefaultReplicationPolicy)
7. Проверка метрик: UnderReplicatedPartitions = 0, consumer lag стабилен

Ссылки на курс: Модуль 11 (Multi-DC, MirrorMaker 2, Active-Passive topology, Offset Translation)

Раздел 6: Мониторинг и ёмкость

Что включить:

Ключевые JMX метрики (минимальный набор):

Ёмкостный план:

Запишите расчёты для пиковой нагрузки 10 000 заказов/сек:

Средний размер события: 500 байт
Суточный объём: 10 000 × 500 × 86 400 = ~432 ГБ/день
С RF=3: 432 × 3 = ~1,3 ТБ/день на диске (суммарно по всем брокерам)
Retention 30 дней: 1,3 × 30 = ~39 ТБ суммарно

Минимум: 3 брокера, рекомендую 6 для запаса
На брокер: 39 / 6 = ~6,5 ТБ диска + 30% headroom = ~8 ТБ SSD
RAM на брокер: 6 ГБ JVM heap + 24 ГБ page cache = 32 ГБ

Ссылки на курс: Модуль 10 (Production Ops: JMX, Prometheus, Capacity Planning)

Критерии оценки

Шаблон документа

Используйте следующий шаблон для своего архитектурного документа:

# Архитектура E-commerce Streaming Platform

## Дата: [дата]
## Автор: [имя]
## Версия: 1.0

---

## Раздел 1: Каталог топиков

| Топик | Партиции | Retention | Cleanup | Схема | Владелец |
|-------|----------|-----------|---------|-------|----------|
| orders.order.created | 12 | 30d | delete | OrderCreated.avsc | order-service |
| ... | | | | | |

Обоснование partition count:
...

---

## Раздел 2: Архитектура сервисов

### Order Service
- Пишет в: ...
- Паттерн: Transactional Outbox (потому что...)
- Consumer group: не применимо (только producer)

### Payment Service
- Читает: ...
- Пишет в: ...
- Exactly-once стратегия: ... (потому что...)

### Saga: хореография или оркестрация?
Решение: ...
Обоснование: ...

---

## Раздел 3: Стриминговый конвейер

Kafka Streams topology:
...

---

## Раздел 4: ACL матрица

| Principal | Topic | Operations |
|-----------|-------|------------|
| order-service | orders.* (PREFIXED) | Write, Describe |
...

---

## Раздел 5: Multi-DC

Topology: Active-Passive MM2
RPO: ... секунд (потому что...)
RTO: ... минут (breakdown: ...)

Failover runbook:
1. ...
2. ...

---

## Раздел 6: Мониторинг и ёмкость

Ключевые алерты:
...

Ёмкость (расчёт):
...

Связь с модулями курса

Задание интегрирует знания из всех предыдущих модулей: