Quando você deve usar Kafka (e quando não)?

Question

Accepted Answer

Kafka é poderoso mas **nem sempre é a ferramenta certa** — se destaca para streaming de eventos em alto volume, pipelines e sistemas orientados por eventos, mas adiciona complexidade operacional que ferramentas mais simples evitam. Entender quando Kafka se adequa (e quando é excessivo) reflete bom julgamento.

## Quando Kafka é uma boa escolha

```text
✓ HIGH-VOLUME event streaming / data → millions of events; high throughput needs
✓ DATA PIPELINES → streaming data reliably between many systems (a data backbone)
✓ MULTIPLE CONSUMERS of the same stream → many independent consumers/groups read the data
✓ EVENT-DRIVEN architecture / event sourcing → events as a durable record
✓ REPLAY needed → re-read historical events
✓ REAL-TIME stream processing / analytics
→ Kafka shines for scale, streaming, retention, and multiple consumers
```

## Quando Kafka pode ser excessivo

```text
⚠️ Kafka adds OPERATIONAL COMPLEXITY (a distributed cluster to run, tune, monitor):
  → SIMPLE messaging / task queues → a simpler queue (RabbitMQ, SQS, Redis) may suffice
  → LOW volume → Kafka's scale is unneeded; simpler tools are easier
  → request/REPLY, complex routing → traditional queues fit better
  → just need a basic background job queue → don't reach for Kafka
→ don't add Kafka's complexity if you don't need its capabilities (YAGNI)
```

## Escolhendo

```text
✓ Use Kafka when you NEED its strengths (scale, streaming, retention, replay, many consumers)
✓ Use simpler tools (RabbitMQ, SQS, Redis, a database) when those suffice
✓ Consider MANAGED Kafka (Confluent, MSK) to reduce operational burden if you do use it
→ match the tool to the actual requirements, not hype
```

## Por que isso importa

Entender quando usar Kafka (e quando não) é valioso porque **Kafka é poderoso mas adiciona complexidade**, então o julgamento de usá-lo apropriadamente importa para decisões de arquitetura sólidas.

Kafka se destaca em certas coisas mas não é uma solução universal, e entender quando se adequa versus quando é excessivo reflete maturidade no julgamento.

Entender **quando Kafka é uma boa escolha** — streaming de eventos em alto volume, pipelines de dados (uma espinha dorsal de dados), múltiplos consumidores do mesmo stream, arquitetura orientada por eventos e event sourcing, necessidades de replay e processamento de stream em tempo real — esclarece onde os pontos fortes de Kafka (escala, streaming, retenção, múltiplos consumidores) o tornam a escolha certa.

Criticamente, entender **quando Kafka pode ser excessivo** é igualmente importante: Kafka adiciona **complexidade operacional significativa** (um cluster distribuído para executar, ajustar e monitorar), então para mensagens simples ou filas de tarefas, baixo volume, request/reply ou filas básicas de jobs em background, **ferramentas mais simples (RabbitMQ, SQS, Redis) geralmente bastam e são mais fáceis** — e adicionar a complexidade de Kafka quando você não precisa de suas capacidades é over-engineering (YAGNI).

Esta perspectiva equilibrada — reconhecendo o poder de Kafka mas também seu custo e que ferramentas mais simples frequentemente são apropriadas — é importante porque Kafka às vezes é adotado por hype ao invés de necessidade.

Entender como **escolher** — usar Kafka quando você precisa de seus pontos fortes (escala, streaming, retenção, replay, muitos consumidores), usar ferramentas mais simples quando essas bastam, e considerar Kafka gerenciado para reduzir carga operacional se você o usar — reflete adequar a ferramenta aos requisitos reais ao invés de hype.

Já que Kafka é poderoso mas adiciona complexidade operacional (então nem sempre é a ferramenta certa) e entender quando se adequa (seus pontos fortes) versus quando ferramentas mais simples bastam (evitando over-engineering) reflete bom julgamento, e já que isso informa decisões de arquitetura de qualidade, entender quando usar Kafka é conhecimento valioso e praticamente relevante — importante para o julgamento de usar Kafka apropriadamente (quando seus pontos fortes são necessários) versus ferramentas mais simples (quando bastam), evitando o over-engineering de adotar a complexidade de Kafka desnecessariamente, e refletindo tomada de decisões de arquitetura sólida e resistente a hype.