Documentation / Daily

21

Day 2 — Kafka Streams

State, time, joins, failures and exactly-once semantics.

LAB-VERIFIEDDAY 02KAFKA 4.3.1

Day 2 — Kafka Streams

30 DAY ENGINEERING LOG / 02

State, time, joins, failures and exactly-once semantics.

StatelessStatefulWindowsJoinsEOS V2

What we studied

Kafka Streams 4.3.1 como uma topologia observável: DSL, tasks, consumer groups, keys, event-time, RocksDB, changelogs, joins e transações EOS V2. Os três labs foram executados contra os brokers Kafka reais e Schema Registry em localhost:8082.

What we built

  • Uma topologia stateless de validação, routing, poison handling e DLQ.
  • Um aggregate stateful em RocksDB com materialização HTTP, changelog e standby replica.
  • Janelas por event-time, grace, stream-stream join e stream-table join.
  • Probes de ALO, EOS V2 e co-partitioning com offsets e isolamento observáveis.

What we broke

Terminámos instâncias e brokers, apagámos estado local, injectámos bytes Avro inválidos e enviámos a mesma key para partitions incompatíveis. ALO reaplicou aggregates. Um join sem distribuição co-partitioned não produziu resultado. No teste 6×3, a falha esperada não ocorreu com o protocolo classic; o protocolo streams falhou antes, na negociação de group.

What we proved

  1. State store local não é a fonte única de recovery: o changelog permite restore.
  2. Standby replica reduz o replay necessário, mas não elimina a operação de failover.
  3. ALO stateful pode reaplicar aggregate e produzir efeitos repetidos.
  4. read_uncommitted pode ver records transacionais que nunca se tornam committed.
  5. EOS V2 torna a visibilidade Kafka transacional: no marker eos-ack-proof-1789082600000, offsets físicos 0,2 ficaram invisíveis a read_committed e offset 4 foi o resultado commitado.

What surprised us

Co-partitioning não é apenas contar partitions. Mesmo com seis de cada lado, um partitioner/distribuição incompatível impediu o join. E a discrepância 6×3 foi concreta: o runtime classic atribuiu nove partitions em vez de falhar como a hipótese inicial previa.

Open discrepancy

A falha de startup 6×3 continua aberta e está marcada como não comprovada no relatório do lab. A documentação não converte essa hipótese em garantia; a recomendação é verificar a versão, protocolo de group e atribuição efetiva no ambiente alvo.