Arquitetando swarms resilientes com event streams Kafka

Um swarm de agentes de IA parece um problema de orquestração. Na prática, é um problema de entrega de mensagens. Cada agente é um consumidor que pode morrer no meio de um efeito colateral, e o orquestrador precisa poder retomar sem duplicar trabalho e sem perder trabalho.

A maioria dos designs que falham nesse cenário cometem o mesmo erro: tratar o broker como um detalhe de transporte. Quando a semântica de entrega é uma decisão de arquitetura, não uma configuração, cada agente individual precisa inventar sua própria estratégia de recuperação — e elas sempre divergem.

O contrato de entrega que realmente importa

Três propriedades, em ordem de importância prática: nenhuma mensagem aceita pode ser perdida; nenhuma mensagem pode ser processada com efeito duplicado; e a ordem deve ser preservada apenas dentro de uma entidade de agregação, nunca globalmente.

1. Configure acks=all e replication.factor mínimo de 3, com min.insync.replicas=2. Um broker que confirma a escrita sem fsync é um incidente futuro.
2. Use chaves de partição estáveis derivadas da entidade, nunca do timestamp de chegada. A chave é o que garante a ordem por agregado e distribui a carga.
3. Registre o offset e o efeito colateral na mesma transação. É o único jeito de tornar a operação idempotente de verdade, e não de forma apenas convencional.

Particionamento é uma decisão de domínio

Round-robin distribui a carga e destrói a ordem. Chave-por-entidade preserva a ordem e cria pontos quentes. Em um swarm de agentes, o padrão certo é chave-por-entidade com uma camada de sal, aplicada apenas quando um agregado específico passa a dominar o tráfego.

# chave de partição: agregado + sal opcional
def partition_key(aggregate_id: str, salt: str | None = None) -> bytes:
    if salt:
        return f"{aggregate_id}#{salt}".encode()
    return aggregate_id.encode()

Consumidores idempotentes na prática

A idempotência não vem de uma biblioteca. Vem de uma restrição de banco ou de um registro de deduplicação consultado antes do efeito. Em sistemas com agentes de IA, há uma camada extra: a resposta do modelo precisa ser identificada pelo hash do prompt mais o da versão do modelo, senão um rebalance reexecuta inferência paga.

Rebalance, DLQ e o que fazer quando o agente não responde

Rebalance é normal, não é uma falha. O que é uma falha é tratar rebalance como erro. Configure session timeout acima do pior caso de processamento, aplique backoff exponencial com jitter no retry e use uma dead-letter queue por-partição com retenção longa o suficiente para auditoria.

Por fim, monitore a taxa de reprocessamento como uma métrica de primeira classe. Um consumer lag de zero com taxa de deduplicação alta é um sistema que está descartando trabalho de forma silenciosa — o pior modo de falha possível, porque os números parecem saudáveis.