Partitions e ordenação

O Capítulo 3 definiu partition como "o log físico propriamente dito". Este capítulo explica por que essa peça específica existe, como ela transforma a escolha de uma key em uma decisão de arquitetura, e por que "o Kafka garante ordenação" é uma frase incompleta até você dizer dentro de quê.

Sem partitions, adicionar mais consumers a um Consumer Group não aumentaria o throughput de consumo — só existiria um único fluxo sequencial para processar. Com partitions, o paralelismo de consumo escala junto com o número de partitions do tópico.

• Paralelismo de consumo: dentro de um Consumer Group, cada partition é atribuída a exatamente um consumer por vez. Mais partitions significa mais consumers processando ao mesmo tempo — até o limite de uma partition por consumer (Capítulo 6 aprofunda o que acontece quando esse limite é ultrapassado).
• Escalabilidade de armazenamento e escrita: partitions de um mesmo tópico podem residir em brokers diferentes. Um tópico com 12 partitions distribuídas em 3 brokers tem 3 vezes mais capacidade de escrita simultânea do que se estivesse inteiro em um único broker.

Quando a mensagem não tem key, o particionador distribui as mensagens entre as partitions de forma aproximadamente uniforme (as versões recentes do client Java usam uma estratégia sticky, que agrupa lotes de mensagens em uma partition por vez antes de rotacionar, otimizando o batching sem comprometer a distribuição). O preço dessa distribuição é que não existe garantia de ordem alguma entre essas mensagens.

Ordenação dentro da partition — e a ausência de ordenação global

Isso decorre diretamente da estrutura de log: uma partition é uma sequência linear e imutável, então a ordem de escrita é, por construção, a ordem de leitura. Mas um tópico com múltiplas partitions não é uma única sequência — é um conjunto de sequências independentes, cada uma com seu próprio relógio de offsets. Duas mensagens em partitions diferentes não têm relação de ordem definida entre si, mesmo que uma tenha sido escrita visivelmente antes da outra em tempo real.

• Se dois eventos do mesmo contaId precisam ser processados na ordem em que ocorreram (ex.: "PIX recebido" seguido de "saldo debitado por estorno"), a key deve ser contaId — não eventId, que geraria melhor distribuição, mas destruiria a ordenação entre esses dois eventos.
• Se os eventos são independentes entre si (não existe relação de ordem que importe), otimizar a distribuição com uma key de alta cardinalidade (ou nenhuma key) é uma escolha válida e melhora o balanceamento de carga entre partitions.

Reduzir o número de partitions de um tópico, por outro lado, não é suportado nativamente pelo Kafka — a única forma é recriar o tópico.

Impactos arquiteturais da escolha de partitions

• Poucas partitions limitam o paralelismo máximo de consumo do Consumer Group e concentram carga de escrita em poucos brokers.
• Partitions demais aumentam o overhead de metadados do cluster, o tempo de rebalance (Capítulo 6) e o número de file handles abertos por broker — sem benefício adicional se não há consumers suficientes para aproveitar o paralelismo extra.
• O número de partitions deve ser dimensionado pelo throughput-alvo e pelo número máximo de consumers que o Consumer Group pretende escalar, não por um valor arbitrário "redondo".