Conceitos
Pull-based consumption model
Intuição
É a diferença entre um garçom que fica te enchendo de pratos no ritmo da cozinha, mesmo que você ainda não tenha terminado o anterior, e um buffet onde você mesmo vai até a mesa e se serve no seu próprio ritmo, guardando de cabeça até onde já comeu. No segundo caso ninguém te afoga de comida, e se você quiser repetir um prato que já passou, basta voltar lá.
Como funciona
No Kafka, consumidores se inscrevem em topics e puxam (pull) mensagens dos brokers, em vez de o broker empurrar (push) mensagens para eles assim que chegam. O broker é 'stateless' em relação ao consumo: ele não guarda quais mensagens cada consumidor já leu; é o próprio consumidor que mantém e avança seu offset dentro de cada partition. Essa escolha resolve o problema clássico de um modelo push, em que o broker precisa adivinhar a taxa certa de envio para cada consumidor — enviar rápido demais satura um consumidor lento, enviar devagar demais desperdiça capacidade de um consumidor rápido. Com pull, cada consumidor busca dados na velocidade que consegue processar, controlando naturalmente seu próprio backpressure, e pode inclusive pedir lotes maiores de mensagens de uma vez para amortizar o custo de rede (batching), o que eleva o throughput. O trade-off explícito é latência: se não há dado novo disponível quando o consumidor pergunta, ele precisa fazer polling repetido (ou esperar numa chamada de long-poll) em vez de ser notificado instantaneamente como aconteceria num push puro. Um efeito colateral bem-vindo de o consumidor guardar seu próprio offset é a capacidade de 'rebobinar' deliberadamente para um offset anterior e reprocessar mensagens já lidas, algo que fica muito mais difícil quando é o broker quem decide e empurra o que já foi entregue.
Na prática
Esse modelo é a razão pela qual sistemas de streaming de eventos como Kafka favorecem throughput e capacidade de replay sobre latência mínima por mensagem, e é a escolha certa quando consumidores têm velocidades de processamento muito diferentes entre si ou precisam reprocessar histórico; sistemas que priorizam latência de entrega imediata acima de tudo (como notificações push) tendem a preferir um modelo de push em vez deste.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.