Event-time vs Processing-time¶

Сравнения · Раздел03

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.

Критерии выбора¶

Критерий	Event-time	Processing-time
Workload / architecture	Business occurrence timestamp/window	Runtime clock/window
Consistency / transaction boundary	Reproducible semantics при versioned events/policy	Outcome зависит от времени исполнения, replay меняет window placement
Latency path	Watermark/late-data completeness trade-off	Нет event-time wait, но late business facts могут учитываться иначе
Throughput / scalability	State windows/timers и out-of-order buffering	Runtime counters/timers; recovery semantics всё равно нужны
Operational complexity / cost	Timestamp quality/watermarks/correction state	Clock/availability/restart и interpretation costs

flowchart TB
  Event[One business event] --> EventTime[Occurrence timestamp]
  Event --> Processing[Runtime arrival clock]
  EventTime --> Watermark[Watermark and late policy]
  Watermark --> Business[Business-time windows]
  Processing --> Admission[Current admission window]
  Replay[Replay at another time] --> Processing

Конкретные сценарии¶

Financial event daily attribution/settlement history → event-time с agreed business calendar и corrections. Online admission rate limit текущих запросов → processing-time может соответствовать цели. В fraud обоих подходов бывает нужно два независимых feature contracts.

Ограничения и восстановление¶

Watermark не гарантирует отсутствие late events. Processing time не автоматически неверен — он отвечает другому вопросу. Сравнивать business meaning, state retention и reproducibility, а не объявлять одну шкалу победителем.

Как проверить выбор¶

Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.

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

Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.

Вопросы на собеседовании¶

Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.

Практические упражнения¶

Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.