Kafka e Logs de Eventos

Seis meses depois de o BoxOffice adotar pub/sub, chegam três pedidos na mesma semana. O time de dados quer carregar todos os eventos de pedido dos últimos sete dias no data warehouse — inclusive eventos publicados antes de o carregador existir. O time de busca lançou um bug que indexou preços errados por duas horas e quer reler essas duas horas depois da correção. E o time de fraude quer todos os eventos do mesmo pedido, em ordem, para detectar padrões de "reserva, libera, reserva, libera" feitos por bots. Uma fila não consegue fazer nada disso: depois que uma mensagem é confirmada, ela some, e consumidores concorrentes embaralham a ordem.

Os três pedidos pedem a mesma coisa: guardar as mensagens, em ordem, e deixar cada leitor decidir de onde ler. Isso é um log, e o Apache Kafka é o sistema que transformou o log na espinha dorsal das arquiteturas de dados modernas¹².

O log

Um log aqui não é um arquivo de texto com mensagens de depuração. É a abstração de armazenamento mais simples que existe: uma sequência de registros só de acréscimo (append-only) e totalmente ordenada. Quem escreve só pode adicionar no fim; cada registro recebe o próximo número sequencial, o seu offset. Quem lê nunca remove nada — cada leitor só lembra o offset até onde chegou.

flowchart LR
    subgraph log ["order-events (uma partição)"]
        direction LR
        r0["0<br/>OrderPlaced<br/>o-1"] --- r1["1<br/>OrderPlaced<br/>o-2"] --- r2["2<br/>OrderConfirmed<br/>o-1"] --- r3["3<br/>OrderCancelled<br/>o-2"] --- r4["4<br/>OrderPlaced<br/>o-3"] --- r5["5<br/>(próxima escrita)"]
    end
    n["notification<br/>offset confirmado 4"] -.-> r4
    a["analytics<br/>offset confirmado 2"] -.-> r2
    w["carregador do warehouse<br/>relendo desde 0"] -.-> r0

Essa mudança minúscula — ler não apaga — tem consequências grandes:

• Qualquer número de leitores independentes. notification, analytics e o carregador do warehouse leem os mesmos dados no seu próprio ritmo. Um leitor lento só fica para trás; não atrasa ninguém.
• Replay. Um leitor pode mover seu offset para trás e reler o histórico (a correção do time de busca), e um leitor novo pode começar do início (o carregador do time de dados).
• Ordem. Os registros são lidos na ordem em que foram escritos — dentro de um log.
• O log é a fonte da verdade sobre "o que aconteceu". Bancos de dados, caches e índices de busca podem ser reconstruídos a partir dele — a ideia por trás de change data capture e event sourcing (Padrões).

Tópicos, partições e offsets

Um único log em uma única máquina limitaria o throughput a um disco e a uma máquina. O Kafka divide cada tópico em partições: cada partição é um log independente, guardado em um broker diferente, com seus próprios offsets. O tópico é apenas o nome de um conjunto de partições.

flowchart LR
    p1["order (réplica 1)"] -->|"chave o-7731"| P1
    p2["order (réplica 2)"] -->|"chave o-1002"| P0
    p2 -->|"chave o-5120"| P2
    subgraph topic ["tópico order-events"]
        P0["partição 0 · broker 1<br/>0 1 2 3 4 5 →"]
        P1["partição 1 · broker 2<br/>0 1 2 3 →"]
        P2["partição 2 · broker 3<br/>0 1 2 3 4 →"]
    end

• Um registro é identificado por (tópico, partição, offset). Os offsets são por partição: o offset 3 na partição 0 e o offset 3 na partição 1 são registros sem relação.
• A ordem só é garantida dentro de uma partição. Dois registros em partições diferentes não têm ordem definida.
• As partições são a unidade de paralelismo: partições diferentes são escritas por brokers diferentes e lidas por consumidores diferentes ao mesmo tempo.
• Em disco, uma partição é uma sequência de arquivos de segmento (por exemplo, 1 GB cada). O Kafka só acrescenta no segmento ativo e apaga ou compacta segmentos antigos inteiros — é isso que torna as escritas sequenciais e baratas.

A chave decide a partição

Cada registro pode ter uma chave. O particionador padrão calcula o hash da chave (murmur2) e toma o resultado módulo o número de partições:

Mesma chave → mesma partição → em ordem. Então a chave é como você diz o que precisa ficar em ordem. Para os eventos de pedido do BoxOffice, a chave é o orderId: OrderPlaced, OrderConfirmed e OrderCancelled do mesmo pedido são sempre lidos em sequência, enquanto pedidos diferentes se espalham pelas partições e são processados em paralelo. Registros sem chave são espalhados pelas partições pelo particionador sticky (ele enche um lote para uma partição e depois passa para outra), sem ordem entre eles.

A chave também decide o balanceamento de carga. A simulação abaixo distribui um minuto de tráfego ilustrativo de abertura de vendas em 12 partições com a própria função de hash do Kafka, usando duas chaves diferentes. No minuto da abertura, 60% das compras são para o show no estádio.

Com chave orderId (à esquerda), cada partição recebe cerca de 1/12 do tráfego. Com chave pelo show (à direita), toda compra do show no estádio cai em uma partição quente: um broker e um consumidor fazem a maior parte do trabalho enquanto os outros ficam ociosos, e adicionar consumidores não ajuda. A lição: escolha a chave com a granularidade mais fina que ainda preserve a ordenação de que o negócio precisa. Eventos de pedido precisam de ordem por pedido, não de ordem por show.

Consumer groups

Um consumer group é um conjunto de instâncias consumidoras que dividem o trabalho de ler um tópico. O Kafka atribui cada partição a exatamente um consumidor do grupo, então cada registro é processado por um membro — consumidores concorrentes, mas com a ordem preservada por partição. Grupos diferentes são totalmente independentes: cada um tem seus próprios offsets confirmados, então cada grupo recebe todos os registros — esse é o fan-out.

flowchart LR
    subgraph topic ["order-events · 6 partições"]
        P0["P0"]
        P1["P1"]
        P2["P2"]
        P3["P3"]
        P4["P4"]
        P5["P5"]
    end
    subgraph gn ["grupo notification · 3 consumidores"]
        N1["notification #1"]
        N2["notification #2"]
        N3["notification #3"]
    end
    subgraph ga ["grupo analytics · 1 consumidor"]
        A1["analytics #1"]
    end
    P0 --> N1
    P1 --> N1
    P2 --> N2
    P3 --> N2
    P4 --> N3
    P5 --> N3
    P0 --> A1
    P1 --> A1
    P2 --> A1
    P3 --> A1
    P4 --> A1
    P5 --> A1

Regras que decorrem de "uma partição, um consumidor por grupo":

• Paralelismo máximo de um grupo = número de partições. Com 6 partições, uma 7ª instância de notification não recebe nada e fica ociosa.
• A ordem por chave se mantém enquanto o consumidor processa os registros de uma partição em sequência. Se ele entrega os registros a um pool de threads, quebra a ordem de novo (a não ser que paralelize por chave).
• Quando um consumidor entra, sai ou fica tempo demais sem fazer poll (max.poll.interval.ms), o grupo faz um rebalance: as partições são redistribuídas. Rebalances clássicos pausavam o grupo inteiro; o protocolo novo (KIP-848, disponível de forma geral no Kafka 4.0) e a atribuição cooperativa movem só as partições que precisam mudar.

Offsets e consumer lag

Um consumidor confirma (commit) o offset do próximo registro que vai ler, por partição; o Kafka guarda os commits em um tópico interno compactado (__consumer_offsets). Depois de um restart ou de um rebalance, o novo dono da partição continua a partir do último offset confirmado. Quando você confirma — antes ou depois de processar — decide se um crash perde ou duplica registros (Semântica de entrega).

O consumer lag é a distância entre o fim da partição e o offset confirmado — quantos registros foram escritos e ainda não processados. É a métrica de saúde de um consumidor:

$ kafka-consumer-groups.sh --bootstrap-server kafka:9092 --describe --group notification

GROUP         TOPIC         PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG    CONSUMER-ID
notification  order-events  0          182340          182355          15     notification-1-...
notification  order-events  1          181902          181910          8      notification-1-...
notification  order-events  2          120004          184771          64767  notification-2-...

A partição 2 está 64.767 registros atrás enquanto as outras estão perto de zero: uma chave quente, um consumidor travado ou uma mensagem venenosa naquela partição — não um problema geral de capacidade. O lag em registros é fácil de ler do Kafka; o lag em segundos (agora menos o timestamp do último registro processado) é o que vai em um SLO de atualidade.

Replicação e durabilidade

Cada partição é replicada em vários brokers — o fator de replicação (RF), tipicamente 3, com as réplicas em zonas de disponibilidade diferentes. Uma réplica é a líder: ela recebe todas as escritas (e, por padrão, atende as leituras). As seguidoras buscam continuamente da líder. As seguidoras em dia formam o conjunto de réplicas sincronizadas (ISR, in-sync replicas). Se o broker da líder falha, o controller elege uma nova líder dentro do ISR.

sequenceDiagram
    participant P as produtor (order)
    participant L as líder P1 (broker 2, AZ-b)
    participant F1 as seguidora (broker 1, AZ-a)
    participant F2 as seguidora (broker 3, AZ-c)
    P->>L: produce OrderConfirmed (acks=all)
    L->>L: acrescenta no offset 4211
    F1->>L: fetch a partir de 4211
    L-->>F1: registro 4211
    F2->>L: fetch a partir de 4211
    L-->>F2: registro 4211
    Note over L: todas as réplicas sincronizadas têm o registro: high watermark = 4212
    L-->>P: ack (offset 4211)
    Note over L,F2: consumidores só veem registros abaixo do high watermark

A configuração acks do produtor escolhe quanto disso o produtor espera:

acks=all sozinho não basta: se o ISR encolhe até só a líder, "todas as réplicas sincronizadas" é uma réplica. min.insync.replicas=2 faz o broker recusar escritas quando há menos de 2 réplicas sincronizadas. Com RF = 3 e min ISR = 2, o tópico continua aceitando escritas com um broker fora do ar e nunca confirma uma escrita que existe em uma só máquina. Mantenha unclean.leader.election.enable=false (o padrão) para que uma réplica desatualizada nunca seja eleita líder. Desde o Kafka 3.0, os produtores usam por padrão acks=all com idempotência habilitada.

Retenção, compactação e armazenamento em camadas

Um log não pode crescer para sempre. Cada tópico tem uma política de limpeza:

Um tópico compactado se comporta como uma tabela que também é um stream: um consumidor novo o lê desde o início e termina com o valor mais recente de cada chave. Apagar uma chave é feito escrevendo um tombstone (a chave com valor null). O próprio __consumer_offsets do Kafka é um tópico compactado.

O armazenamento em camadas (tiered storage, pronto para produção desde o Kafka 3.9) mantém só os segmentos recentes nos discos dos brokers e move os segmentos antigos para object storage (S3, GCS, Azure Blob). Retenção longa — meses de eventos para replay — fica barata, e os brokers ficam mais leves de substituir.

Por que o Kafka é rápido

Um broker Kafka movimenta com frequência centenas de megabytes por segundo em hardware comum. Vale conhecer os motivos, porque eles reaparecem em muitos sistemas³:

• I/O sequencial. As escritas vão para o fim de um arquivo de segmento; as leituras de consumidores em dia vêm da mesma região recente. Acesso sequencial a disco é ordens de grandeza mais rápido que acesso aleatório (veja Números).
• O page cache do sistema operacional. O Kafka não mantém um cache próprio; ele deixa o sistema operacional guardar em memória os segmentos recentes, então consumidores em dia leem da RAM.
• Zero-copy. Para servir um consumidor, o broker pede ao kernel que envie os bytes do arquivo direto para o socket (sendfile), sem copiá-los pela aplicação.
• Lotes e compressão. Os produtores agrupam registros em lotes por partição (linger.ms, batch.size) e comprimem lotes inteiros (zstd, lz4). Menos requisições, e maiores; menos bytes em disco e na rede.
• Particionamento. A carga se espalha por muitos brokers e muitos consumidores.

O custo é latência: os lotes adicionam alguns milissegundos (linger.ms), e acks=all adiciona uma ida e volta de replicação. A latência típica de ponta a ponta fica entre alguns e dezenas de milissegundos — ótimo para eventos, mas não substitui uma chamada RPC em memória.

Dimensionando partições

Partições são baratas, mas não de graça (mais arquivos, mais eleições de líder, rebalances mais longos, mais memória nos clientes). Uma regra inicial comum⁴: com um throughput-alvo \(T\), um throughput de produtor medido por partição \(p\) e um throughput de consumidor por partição \(c\),

e depois arredonde para cima com folga para crescimento, porque aumentar partições depois move as chaves.

O tópico é criado explicitamente (nunca dependa de criação automática em produção):

kafka-topics.sh --bootstrap-server kafka:9092 --create --topic order-events \
  --partitions 24 --replication-factor 3 \
  --config min.insync.replicas=2 \
  --config retention.ms=604800000 \
  --config compression.type=zstd

E os serviços Spring Boot configuram seus clientes de acordo:

spring:
  kafka:
    bootstrap-servers: kafka:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JacksonJsonSerializer
      acks: all                    # wait for every in-sync replica
      properties:
        enable.idempotence: true   # producer retries do not duplicate records
        linger.ms: 5               # wait up to 5 ms to fill a batch
        compression.type: zstd

spring:
  kafka:
    bootstrap-servers: kafka:9092
    consumer:
      group-id: notification
      auto-offset-reset: earliest  # a brand-new group starts from the oldest record
      enable-auto-commit: false    # the container commits after processing
      max-poll-records: 100
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.springframework.kafka.support.serializer.JacksonJsonDeserializer
      properties:
        spring.json.trusted.packages: "boxoffice.events"
    listener:
      ack-mode: record             # commit the offset after each record
      concurrency: 3               # 3 consumer threads in this instance

kafka:
  image: apache/kafka:4.3.1
  hostname: kafka
  ports:
    - "9094:9094"
  environment:
    KAFKA_NODE_ID: 1
    KAFKA_PROCESS_ROLES: broker,controller
    KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
    KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094
    KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,EXTERNAL://localhost:9094
    KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT
    KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
    KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
    KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
    KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
    KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
    KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
    KAFKA_AUTO_CREATE_TOPICS_ENABLE: "false"
kafka-init:
  image: apache/kafka:4.3.1
  depends_on:
    kafka:
      condition: service_healthy
  entrypoint: ["/bin/sh", "-c"]
  command:
    - |
      /opt/kafka/bin/kafka-topics.sh --bootstrap-server kafka:9092 --create --if-not-exists \
        --topic order-events --partitions 6 --replication-factor 1 &&
      /opt/kafka/bin/kafka-topics.sh --bootstrap-server kafka:9092 --create --if-not-exists \
        --topic order-events-dlt --partitions 6 --replication-factor 1
  restart: "no"

O Kafka e suas alternativas

O Redpanda e o Azure Event Hubs expõem o protocolo do Kafka, então clientes Kafka funcionam com eles sem mudanças. O próprio Kafka também está ganhando semântica de fila: os share groups ("Queues for Kafka", KIP-932, introduzidos no Kafka 4.0) deixam vários consumidores dividirem uma partição com confirmação por registro, como uma fila clássica.

Como se conecta

flowchart LR
    LOG["log só de append<br/>offsets"] --> PART["partições<br/>unidade de paralelismo"]
    KEY["chave = orderId<br/>murmur2 mod N"] --> PART
    PART --> ORD["ordem por chave<br/>→ Semântica de entrega"]
    PART --> CG["consumer groups<br/>um consumidor por partição"]
    CG --> LAG["consumer lag<br/>→ Observabilidade"]
    PART --> REP["RF 3, acks=all,<br/>min.insync.replicas=2"]
    REP --> KRAFT["controllers KRaft<br/>→ Consenso (aula 3)"]
    LOG --> RET["retenção, compactação,<br/>armazenamento em camadas"]
    LOG --> REPLAY["replay: CDC, event sourcing<br/>→ Padrões"]
    PART --> SIZE["N ≥ max(T/p, T/c)<br/>→ Estimativas"]
    KEY --> HOT["chave quente, hash mod N move chaves<br/>→ Particionamento"]

Componentes da paleta: kafka · stream (o equivalente gerenciado: Kinesis, Event Hubs) · objstore (armazenamento em camadas) · dwh (o loader do warehouse faz replay do log) · notifications · analytics · search (consumer groups lendo cada um no seu ritmo). Cenários: event-fanout. Continua em: Semântica de entrega, Padrões, Distribuídos — consenso (KRaft é Raft), Bancos de dados — particionamento (chaves quentes, resharding), Observabilidade — sinais (lag como métrica), Hands-on 7 — Kafka.