Consumer Groups e Particionamento

Múltiplas instâncias do Payment Service

Escalando payment-service com consumer group no Docker Compose.

Avançado 40 min 35 pontos Leitura 0%

Nesta aula você vai

  • Escalar payment-service horizontalmente no Docker Compose
  • Distribuir carga entre replicas no mesmo consumer group
  • Validar ganho de throughput sem duplicacao de processamento

Múltiplas instâncias do Payment Service

Objetivos

  • Escalar Payment Service horizontalmente no Compose
  • Distribuir carga de consumo entre réplicas no mesmo grupo
  • Validar ganho de throughput sem duplicação

Pré-requisitos

  • Aulas anteriores da materia 12 concluidas.
  • Topico order.created com ao menos 3 particoes.
  • Configuracao de idempotencia ativa no payment-service.

Conceito

Escalar payment-service com consumer group permite processar mais eventos em paralelo sem duplicar a leitura dentro do mesmo grupo.

Com particoes suficientes e replicas alinhadas, cada instancia recebe subconjunto de particoes e aumenta throughput.

Estrutura de arquivos

  • infra/docker-compose.scale.yml
  • docker-compose.yml
  • services/payment-service/internal/consumers/order_created_consumer.go
  • infra/kafka/topics/create-topics.sh

Passo a passo com codigo

  1. Defina configuracao base sem porta fixa no payment:
payment-service:
  build: ./services/payment-service
  environment:
    KAFKA_GROUP_ID: payment-consumers-v1
  depends_on:
    - kafka
  1. Suba 3 replicas:
docker compose up -d --scale payment-service=3
  1. Gere carga de pedidos:
python scripts/load/publish_order_created.py --count 500 --parallel 10
  1. Exponha metrica por instancia:
processedTotal.WithLabelValues(os.Getenv("HOSTNAME")).Inc()

Como testar

  1. Compare tempo para processar 500 eventos com 1 replica e depois com 3.
  2. Verifique que cada replica registra eventos distintos.
  3. Confirme ausencia de duplicidade com tabela processed_events.
  4. Observe reducao de lag no consumer group.

Dicas

  • Escale replicas ate o limite de particoes.
  • Use shutdown gracioso para minimizar rebalance.
  • Observe metricas por instancia, nao apenas total.
  • Mantenha group.id identico entre replicas.

Erros comuns

  • Subir réplicas com group id diferente sem intenção
  • Não ajustar recursos de CPU e memória por instância
  • Ignorar impacto de rebalance em deploy
  • Assumir distribuição perfeita sem monitoramento

Resumo

Com multiplas instancias no mesmo consumer group, o payment-service aumenta throughput de forma previsivel, desde que particoes, group id e idempotencia estejam corretos.