Conceitos
Partitioned commit log
Intuição
Pense num caderno de atas onde cada linha nova é numerada e escrita sempre no final, nunca apagada nem editada no meio — quem quiser saber o que aconteceu é só olhar a partir de um certo número de linha e ir lendo pra frente. Agora imagine que, em vez de um caderno só, você usa vários cadernos em paralelo, cada um cuidando de uma fatia do assunto, pra várias pessoas poderem escrever e ler ao mesmo tempo sem disputar o mesmo caderno.
Como funciona
No Kafka, um fluxo de mensagens de um tipo é um topic, e cada topic é dividido em múltiplas partitions para permitir escala horizontal. Cada partition é armazenada fisicamente como um log simples — um conjunto de arquivos de segmento aos quais o broker apenas faz append sequencial, nunca escrita ou edição no meio. Uma mensagem não tem um ID explícito atribuído pelo sistema: ela é identificada pelo seu offset, a posição dela dentro do log daquela partition, o que evita manter estruturas de índice caras. Essa estrutura de log append-only traz duas vantagens diretas: primeiro, o I/O é sequencial tanto para produtores quanto para consumidores, o que é ordens de grandeza mais rápido em disco do que I/O aleatório, e permite ao Kafka apoiar-se no page cache do sistema operacional em vez de manter cache próprio; segundo, como o dado não é apagado ao ser lido (a retenção é por tempo, não por confirmação de leitura), qualquer consumidor pode voltar a um offset anterior e reprocessar o histórico. O número de partitions de um topic é o que determina o grau de paralelismo possível: dentro de um consumer group, cada partition é consumida por exatamente um consumidor por vez, então mais partitions permitem mais consumidores processando o mesmo topic em paralelo, ao custo de a ordem só ser garantida dentro de cada partition, nunca entre partitions diferentes do mesmo topic.
Na prática
Esse desenho é a base de qualquer plataforma de streaming de eventos moderna (Kafka e seus descendentes) usada para desacoplar produtores e consumidores em arquiteturas orientadas a eventos, pipelines de ingestão para data warehouse/Hadoop, ou feeds de atividade quase em tempo real; a escolha do número de partitions de um topic é literalmente a escolha de quanto paralelismo de consumo aquele fluxo vai suportar.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.