Streaming-first Architecture¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Уровень: приоритет оперативного data path и эксплуатационная стратегия. Проверка источников: 2026-11-02.

1. Назначение и решаемая проблема¶

Streaming-first означает, что основная оперативная ценность данных доставляется непрерывным потоком, а batch/backfill поддерживает этот путь. Это принцип проектирования, не единый стандартизованный stack и не запрет batch jobs.

Он полезен, когда свежие события влияют на решения: fraud features, active market state, оперативные limits. Сначала нужно определить, какое решение устаревает и какой деградацией оно может пользоваться; затем выбирать engine.

2. Принцип работы¶

Source фиксирует accepted changes, transport сохраняет input, processing обновляет state и serving layer. Вокруг live path проектируются schema evolution, backpressure, archival history и безопасный backfill.

Архитектура может быть Kappa, если historical recomputation использует единый processing model, либо содержать Lambda для отдельного authoritative analytical recompute. Medallion, CQRS и Outbox отвечают на другие вопросы и также совместимы.

3. Архитектурная схема¶

flowchart TB
    D["Authoritative source + intent"] --> L["Durable event stream"]
    L --> P["Live processing и state"]
    P --> V["Serving projection с freshness"]
    V --> U["Оперативный consumer"]
    L --> A["Archive и schemas"]
    A --> R["Isolated backfill generation"]
    R --> X["Reconciliation и controlled cutover"]
    X --> V
    V --> M["Lag / quality observability"]

4. Walkthrough движения данных¶

Source признаёт бизнес-изменение по собственному transaction contract и создаёт delivery intent.
Stream envelope переносит identity, business revision, event time и schema; partition key соответствует ordering scope.
Live processor обновляет нужные features/projections; event-time policy определяет late events и corrections.
Serving возвращает state вместе с revision/updated coverage. Decision service проверяет, достаточно ли свежи features для конкретного действия.
При деградации применяются заранее заданные fallback/admission rules: например сохранить pending или временно запретить операции, которым нужен отсутствующий актуальный state.
Archive позволяет строить новое поколение без повторения live business actions. Сверка определяет безопасный cutover.
Recovery проверяет не только consumer lag, но и source completeness, quality и согласованность результата с authoritative owner.

5. Технологии реализации¶

Transport Kafka/Pulsar; Flink/Kafka Streams/Spark для обработки; low-latency state/query stores и archive. CDC и Outbox могут быть source adapters; Schema Registry и lineage поддерживают evolution.

Реальный выбор должен учитывать состояние и connectors. «Streaming-first» не означает «везде Flink»: простому projection достаточно idempotent consumer, а регулярному отчёту — batch.

6. Консистентность и гарантии обработки¶

Каждая граница имеет отдельный контракт. Source commit не равен visible projection, и visible feature не гарантирует однократный payout. Для внешнего decision/effect нужен собственный idempotency и transaction/reconciliation protocol.

Replayable source и transactional/idempotent sink — необходимые части end-to-end recovery design, но не гарантия правильного domain rule. FACT: Flink 1.20 различает exactly-once state и end-to-end source/sink conditions. Flink. Нельзя приписывать это всему streaming-first stack.

Watermark не свидетельствует, что все реальные события уже пришли. Finality отчёта или settlement определяется domain rules, не только движком.

7. Отказы и восстановление¶

Сбой	Recovery и деградация	Критерий выхода
Source недоступен	Не выдумывать новые accepted events	Подтверждённая source continuity
Lag превысил допустимую свежесть	Ограничить зависимые decisions	Coverage догнала требуемую границу
Checkpoint/state потерян	Restore или isolated replay	Сверены state и sink
Poison schema	Quarantine + owner repair	Missing range обработан, не просто offset сдвинут
Backfill перегрузил sink	Throttle/отделить ресурсы	Live path стабилен и дубликаты исключены

Работающий broker с неработающей системой interventions не считается healthy end-to-end.

8. Масштабирование и узкие места¶

Планировать три нагрузки: normal live, burst и recovery/backfill. Если target не выдерживает одновременно live и catch-up, нужны приоритеты и изоляция, а не безграничное увеличение consumer count.

State size, key skew, checkpoint storage, joins и external lookups обычно ограничивают масштаб. Несколько downstream consumers увеличивают стоимость; streaming-first без ownership превращает каждый replay в межкомандный incident.

9. Преимущества и недостатки¶

Плюсы: свежие data products, меньше batch-induced delay, понятная live processing модель. Минусы: постоянная эксплуатация, сложная time/state semantics, необходимость деградации и архивирования.

Стратегия не нужна там, где action выполняется раз в сутки и бизнес не получает пользы от более свежих данных. Freshness без корректности и понятной finality может быть вреднее задержки.

10. Альтернативные решения¶

Lambda vs Kappa vs Streaming-first отделяет execution/recompute от приоритета live path. Batch-first подходит для редких регламентных расчётов; request/response — для решения у одного authoritative owner. Гибрид часто разумнее догматического запрета batch.

11. Реальные примеры и границы подтверждения¶

FACT: Betfair описывает замену database polling потоковой доставкой market data. Это пример streaming-oriented read path. Источник.

FACT: slides BEC/Scoutz показывают mainframe-to-Kafka processing и отдельный reconciliation loop. Banking material. INFERENCE: такие проекты иллюстрируют live-first integration, но не доказывают, что авторы используют именно термин streaming-first.

12. Применение в FinTech и iGaming¶

FinTech: свежие fraud features и transaction visibility при сохранении authoritative payment/ledger boundary. Отсутствующий feature требует явной risk policy, а не default «разрешить».

iGaming: odds distribution и monitoring активности; критический self-exclusion/limit check может требовать синхронного authoritative enforcement. Потоковая аналитика помогает, но не доказывает, что запрещённая ставка не будет принята.

13. Типичные ошибки проектирования¶

Подменять business freshness одним broker lag.
Не проектировать degraded state и unknown outcome.
Запускать replay с боевыми side effects.
Считать watermark доказательством полной истории.
Выбирать streaming для всех jobs без оценки пользы.

14. Вопросы технического интервью с ответами¶

Streaming-first — альтернатива Kappa? Нет, это разные оси. Live-first система может иметь unified replay или отдельный batch correction path.

Как определить freshness? По конкретному потребителю, source coverage и возрасту нужных данных, а не только времени последнего heartbeat.

Почему быстро обновлённая feature может быть некорректной? Возможны missing input, неверная identity, stale reference data и семантическая ошибка. Скорость обработки не доказывает качество.

15. Практическое упражнение¶

HYPOTHETICAL: live risk feature отстаёт, broker доступен, source продолжает принимать события. Опишите admission/degraded policy и dashboard сигнал для decision owner.

Ожидается явное различие между «pipeline жив» и «данных достаточно для решения», isolated backfill и критерий reconciliation перед возвратом normal mode. Числовые SLO нужно согласовать с бизнесом; чужие latency claims не переносить.

Дополнительные источники¶

Flink 1.20 fault tolerance; Betfair; BEC slides.