Lambda com filas do Kafka: paralelismo acima das partições, e o que ele custa

No modo Stream (o padrão), o ESM usa o protocolo de consumer group: cada partição pertence a exatamente um consumidor. A documentação do Lambda é explícita sobre a consequência: em provisioned mode, para manter a ordem dentro da partição, o MaximumPollers é limitado ao número de partições do tópico, e cada poller sustenta até 5 MB/s ou até 5 invocações concorrentes.

Faça a conta para um tópico de 12 partições: 12 pollers vezes 5 invocações dá 60 execuções simultâneas, no máximo. Se o handler chama um modelo de fraude que leva 800 ms, o teto é algo perto de 75 registros por segundo por lote unitário, e não há ReservedConcurrentExecutions que mude isso.

As duas saídas tradicionais têm custo de manutenção, não de construção:

• Superparticionar: 12 vira 96. A chave de partição muda de distribuição, o rebalanceamento fica mais lento, o broker carrega mais arquivos de segmento e réplicas, e quase nunca se volta atrás, porque reduzir partição no Kafka não existe.
• Copiar para outra fila: um consumidor que republica em SQS. Agora você opera duas filas, duas políticas de retenção, dois pontos de duplicação e um código de ponte que alguém precisa manter atualizado.

Para trabalho em que cada evento é unidade independente (codificação de mídia, notificação, ingestão de telemetria, scoring de fraude por transação), pagar o preço da ordenação sem precisar dela é desperdício puro.

O KIP-932 troca a posse da partição por posse do registro. O broker mantém uma janela de registros em voo por partição, entre o share-partition start offset (SPSO) e o end offset (SPEO). Cada consumidor que busca dados adquire um lock temporário sobre registros, não sobre a partição. Ao final, o consumidor reconhece cada registro com um de três tipos: ACCEPT (processado), RELEASE (devolve para nova tentativa) ou REJECT (não processável, não volta).

Três parâmetros de grupo governam o comportamento, todos configuráveis por grupo com kafka-configs.sh --entity-type groups e limitados pelos mínimos e máximos do broker:

• share.record.lock.duration.ms: quanto tempo o lock vale. O padrão é 30 s; expirou, o registro volta a ficar disponível para outro consumidor.
• share.delivery.count.limit: quantas entregas um registro recebe antes de ser arquivado. O padrão é 5.
• share.partition.max.record.locks: quantos registros podem estar travados ao mesmo tempo por partição. É o teto real de paralelismo dentro de uma partição.

O Kafka 4.2, lançado em 17/02/2026, declarou os share groups prontos para produção e acrescentou o tipo RENEW, para estender o lock em processamento longo.

No Lambda, o ESM em Queue mode usa o Kafka Share Consumer: cada event poller lê de todas as partições, sem ordenação por partição, e sustenta até 10 invocações concorrentes, o dobro do modo Stream. O payload do evento continua idêntico ao do Kafka tradicional, com topic, partition e offset, então o código da função não muda.

Ligar é uma linha: SelfManagedKafkaEventSourceConfig.ConsumptionMode: Queue. Operar é outra conversa. Quatro decisões fazem a diferença.

Escala: o on-demand do Queue mode para em 5 pollers, a 1 MB/s cada, ou seja 5 MB/s ou 50 invocações, o que vier primeiro. Para pico de verdade, provisioned mode: MinimumPollers de 1 a 200, MaximumPollers de 1 a 2.000, cada poller com até 5 MB/s. Na prática quem limita é a concorrência da função: 40 pollers vezes 10 são 400 execuções, e a cota padrão de concorrência da conta precisa comportar isso sem estrangular o resto.

Lock versus timeout: o lock padrão é 30 s. Se o lote de 100 registros leva 45 s na função, o broker considera o lock expirado e entrega os mesmos registros a outro poller. A documentação que li não diz se o poller renova o lock, então eu trato share.record.lock.duration.ms maior que o timeout da função como regra, e BatchSize pequeno o bastante para caber nele.

Custo: provisioned mode cobra por EPU-hora, US$ 0,185 em us-east-1 no exemplo da própria documentação, e um EPU comporta 10 pollers por padrão. ESMs em Queue só compartilham PollerGroupName com outros ESMs em Queue; misturar com Stream retorna erro de validação.

Backlog: não existe StartingPosition. Share group novo começa no offset mais recente, então um ESM criado sobre um tópico com fila acumulada ignora o acumulado até alguém ajustar share.auto.offset.reset no grupo.

Use Queue mode quando três coisas forem verdade ao mesmo tempo: cada evento é unidade de trabalho independente, o handler é idempotente por uma chave de negócio (não pelo offset) e o gargalo medido é concorrência da função, não throughput do broker. Scoring de fraude por transação, envio de push e e-mail, thumbnail e transcodificação, enriquecimento de telemetria: todos passam nesse teste.

Não use quando o estado depende da sequência. Lançamento contábil por conta, máquina de estado de pedido, atualização de saldo, CDC que aplica UPDATE depois de INSERT: qualquer coisa em que "o evento 2 antes do evento 1" produz um número errado. Em sistema financeiro, isso não é bug de performance, é divergência de razão que alguém concilia na mão no fechamento.

Também não use como atalho para não entender o próprio lag. Se o consumidor está atrasado porque o handler faz uma chamada síncrona de 3 s a um sistema legado com 20 conexões no pool, dobrar a concorrência só move a fila do Kafka para o legado, e agora ele cai junto. O paralelismo novo precisa de um limite explícito na ponta: ReservedConcurrentExecutions na função ou MaximumPollers calculado a partir da capacidade de quem recebe a chamada.

E note o recorte do lançamento: só Kafka self-managed e Confluent Cloud, em versão 4.2 ou superior com share groups habilitados. Amazon MSK fica para quando oferecer essa versão.