Pipeline de Dados com Kafka para SaaS: Introdução Prática

Kafka não é para todo SaaS (e isso é bom)

Kafka é poderoso e Kafka é complexo. Para muitos SaaS, adicionar Kafka prematuramente é over-engineering que adiciona custo operacional sem benefício proporcional.

Este guia ajuda você a tomar a decisão certa: quando Kafka realmente faz sentido, o que ganhar com ele, e quando BullMQ ou SQS são escolhas melhores.

O que o Kafka faz que outros sistemas não fazem

Kafka é um log distribuído de eventos persistente. Os diferenciais importantes:

Replay de eventos

Eventos ficam no Kafka por um período configurável (padrão: 7 dias, mas pode ser semanas ou meses). Qualquer consumidor pode reprocessar eventos históricos do início ou de um ponto específico.

Caso de uso: você lança um novo serviço de analytics que precisa processar todos os eventos de pagamento dos últimos 30 dias. Com SQS ou BullMQ, os eventos sumiram. Com Kafka, você rebobina o offset e reprocessa.

Múltiplos consumidores independentes

Em SQS/BullMQ, um job é consumido por um worker e deletado. No Kafka, cada consumer group tem seu próprio offset — o mesmo evento pode ser processado por múltiplos serviços independentes.

Evento: "subscription.upgraded"
  → Consumer Group: billing-service     (atualiza plano no banco)
  → Consumer Group: notification-service (envia e-mail de confirmação)
  → Consumer Group: analytics-service   (atualiza métricas de MRR)

Com SQS, você teria 3 filas separadas e um "fan-out" manual. Com Kafka, os três serviços simplesmente assinam o mesmo tópico.

Ordem garantida por partition key

Kafka garante ordem dentro de uma partition. Se você usar tenant_id como partition key, todos os eventos de um tenant chegam ao consumidor em ordem — útil para event sourcing e auditoria.

Quando Kafka faz sentido no seu SaaS

Avalie Kafka quando você tem dois ou mais destes sinais:

Múltiplos serviços precisam reagir aos mesmos eventos
Volume alto: > 10.000 eventos por segundo consistentemente
Replay de eventos é necessário (novo serviço precisa de histórico, recuperação de erro)
Event sourcing: o estado do sistema é derivado de eventos imutáveis
Analytics em tempo real: stream de eventos alimenta dashboards e alertas
Auditoria: trilha de auditoria imutável é requisito de compliance

Se você tem apenas uma fila de jobs para processamento assíncrono simples, BullMQ + Redis (Node.js) ou SQS (AWS) são muito mais simples.

Arquitetura com Kafka em SaaS multi-tenant

Aplicação SaaS
  └→ Kafka Producer (publica eventos com tenant_id)
       └→ Tópicos por domínio:
            subscriptions    (criação, upgrade, downgrade, cancelamento)
            payments         (cobrança, estorno, falha)
            user-activity    (login, ação no produto, export)
            notifications    (requisição de envio de e-mail/push)

Consumers:
  └→ billing-worker      (consumer group: billing)
  └→ analytics-ingester  (consumer group: analytics → ClickHouse)
  └→ notification-sender (consumer group: notifications)
  └→ audit-logger        (consumer group: audit)

Convenções que economizam dor

Nomeação de tópicos: {domínio}.{entidade}.{evento} é mais escalável que nomes genéricos:

payments.subscription.created
payments.subscription.cancelled
users.account.deleted
billing.invoice.paid

Schema Registry: use Avro ou Protobuf com um Schema Registry (Confluent ou AWS Glue) para garantir compatibilidade de schema entre produtores e consumidores. Sem isso, uma mudança de schema quebra consumers sem aviso.

Dead Letter Queue (DLQ): configure um tópico DLQ para mensagens que falharam após N tentativas. Facilita investigação e reprocessamento seletivo.

Kafka vs. SQS vs. BullMQ: quando usar cada um

| Critério | BullMQ + Redis | Amazon SQS | Apache Kafka | |---|---|---|---| | Múltiplos consumers por evento | ✗ | ✗ (precisa SNS fan-out) | ✓ nativo | | Replay de eventos | ✗ | ✗ | ✓ | | Throughput | Médio (~10k/s) | Alto | Muito alto (> 1M/s) | | Latência | Baixa (<10ms) | Média (10–100ms) | Baixa (<10ms) | | Operação | Simples | Gerenciado pela AWS | Complexo (ou MSK) | | Custo inicial | US$ 10–30/mês (Redis) | Pay-per-message | US$ 200+/mês (MSK) | | Melhor para | Job queues simples, MVP | Desacoplamento de serviços | Event streaming, analytics |

Recomendação por fase

MVP e primeiros 12 meses: BullMQ + Redis. Simples, sem infra extra, cobre 95% dos casos.

Crescimento com múltiplos serviços: avalie SQS + SNS para fan-out simples. Gerenciado pela AWS, sem servidor para operar.

Escala ou evento sourcing: Kafka via MSK (Managed Streaming for Kafka da AWS) ou self-hosted com Kubernetes.

Implementação básica: produtor em TypeScript

import { Kafka } from 'kafkajs'

const kafka = new Kafka({
  clientId: 'saas-app',
  brokers: [process.env.KAFKA_BROKER!],
  ssl: true,
  sasl: {
    mechanism: 'plain',
    username: process.env.KAFKA_USERNAME!,
    password: process.env.KAFKA_PASSWORD!,
  },
})

const producer = kafka.producer()

export async function publishEvent<T>(topic: string, event: {
  tenantId: string
  type: string
  payload: T
}) {
  await producer.send({
    topic,
    messages: [{
      key: event.tenantId,          // partition key: mesmo tenant → mesma partition
      value: JSON.stringify(event),
      headers: {
        'event-type': event.type,
        'published-at': new Date().toISOString(),
      },
    }],
  })
}

// Uso:
await publishEvent('payments.subscription', {
  tenantId: 'acme',
  type: 'subscription.upgraded',
  payload: { planId: 'pro', previousPlanId: 'starter', userId: '...' },
})

Armadilhas comuns

Não ignore idempotência: networks falham, producers fazem retry, eventos duplicados chegam. Seu consumer deve tratar o mesmo evento duas vezes sem efeito colateral. Use o event.id como chave de deduplicação no banco.

Não use um tópico para tudo: um tópico genérico events com todos os tipos de evento misturados dificulta o controle de retenção, Schema Registry e permissões por serviço.

Não negligencie monitoring: monitore lag dos consumer groups — o número de mensagens não processadas. Um consumer parado acumula lag silenciosamente até o offset ultrapassar a retenção e perder eventos.

Para discussões de arquitetura sobre quando e como implementar Kafka (ou uma alternativa mais simples) no seu SaaS:

Falar com especialista em engenharia de dados → · Engenharia de dados para SaaS → · Stack tecnológica SaaS 2025 →