Consumidores no contexto de sistemas distribuídos
Quando alguém pergunta o que é consumidores, a resposta mais direta é: são agentes (processos, serviços ou máquinas) que recebem e processam mensagens de uma fila ou tópico. A teoria é simples. A prática costuma ser bem mais bagunçada. Um consumidor funciona como um leitor dedicado. Ele se conecta a um broker — Kafka, RabbitMQ, SQS, Pub/Sub — e puxa mensagens conforme aparecem. Pode processar em lote, um por um, ou de forma assíncrona com múltiplas threads. O modelo básico não é controverso, mas os detalhes de implementação é onde as coisas quebram.
o que é consumidores na prática
No dia a dia, um consumidor tem três responsabilidades: receber, processar e confirmar. A confirmação (ack) é o ponto mais negligenciado. Se você não confirma a mensagem corretamente, o broker pode reentregar, duplicar processamento, ou pior, perder dados silenciosamente. Trabalhei num sistema onde o ack era feito antes do processamento real terminar por causa de um erro de ordem nas chamadas. As mensagens eram confirmadas enquanto ainda estavam sendo tratadas. O resultado foi perda de dados em produção e uma manhã inteira de correção. A solução foi inverter a ordem: processar primeiro, confirmar depois, e só então liberar a próxima mensagem. Simples, mas exige cuidado com timeout. Se o processamento demora, o broker pode interpretar como falha do consumidor e reposicionar a mensagem.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que é consumidores também envolve entender o balanço entre throughput e consistência. Quanto mais rápido você consome, mais pressão coloca no sistema downstream. Em certa ocasião, um consumidor estava lendo do Kafka a quase 10 mil mensagens por segundo, mas o banco de dados PostgreSQL por baixo não suportava. As queries entravam em deadlock e o consumo efetivo caía para zero porque tudo travava. Ajustei o prefetch count para 10 mensagens e adicionei um throttle com rate limiter. O throughput caiu para cerca de 200 por segundo, mas o sistema ficou estável. Melhor assim do que colapsar. Outro ponto que iniciantes geralmente ignoram é o gerenciamento de estado do consumidor. Se o serviço reinicia, ele precisa saber onde parou. Em sistemas como Kafka, isso é o offset. Em SQS, é o message ID e a visibilidade. Se você não gerencia isso direito, vai processar as mesmas mensagens duas vezes ou pular partes da fila. Recomendo manter um log de offsets local com checkpoint periódico. Não confie exclusivamente na persistência do broker para recuperação de estado.
Há também o problema dos consumidores lentos que arrastam o grupo todo. Em um consumer group, se uma instância processa devagar, as mensagens acumulam e o lag cresce. A solução padrão é escalar horizontalmente, mas às vezes o gargalo não é velocidade, é dependência externa. API de terceiro com rate limit, banco de dados lento, serviço orquestrado com latência alta. Nesses casos, adicionar mais consumidores não ajuda. O que resolve é colocar um buffer entre o consumidor e a chamada externa, talvez com um worker pool com limite de conexões simultâneas. Se o seu cenário é simples, como filas pequenas com poucos consumidores, SQS ou até RedisLists podem ser suficientes. Para sistemas que precisam de replay de eventos, ordenação garantida ou alto volume, Kafka ou um broker similar é mais adequado. A escolha do broker impacta diretamente como você projetará os consumidores.
