🤝 Por que consenso?
Em swarms pequenos (2-4 agentes), coordenação é trivial. Em swarms grandes (10+), surgem conflitos de estado, falhas parciais e race conditions. Algoritmos de consenso garantem que os agentes concordam sobre a verdade mesmo com falhas.
🎯Quando você precisa de consenso
- •Swarms grandes — coordenação 10+ agentes
- •Tolerância a falhas — agente cai sem corromper estado global
- •Decisões críticas — deploy, merge, release management
- •Estado compartilhado — multiple writers em memória global
📊Trade-offs gerais
- Latência vs consistência — quanto mais forte, mais lento
- Tolerância vs throughput — Byzantine é mais robusto mas mais caro
- Simplicidade vs flexibilidade — Raft é simples, CRDT mais flexível
👑 Raft (default em Ruflo)
Raft é leader-based. Um nó é eleito líder; ele recebe todos os writes e replica para os followers. Tolera f < n/2 falhas (em 5 nós, aguenta 2 quedas). É o default em Ruflo por simplicidade e eficiência para coding.
👑As 3 fases do Raft
- Leader Election — quando líder cai, candidatos pedem votos
- Log Replication — líder envia AppendEntries para followers
- Safety — committed entries nunca são perdidas
✓ USE Raft quando
- ✓Coding tasks com 4-8 agentes
- ✓Você quer simplicidade
- ✓Todos os agentes são confiáveis
- ✓Latência baixa importa
✗ EVITE Raft quando
- ✗Pode haver atores maliciosos
- ✗Mais de 100 agentes
- ✗Particionamento de rede frequente
- ✗Updates concorrentes massivos
🛡️ Byzantine BFT
Byzantine Fault Tolerance lida com o pior cenário: nós que mentem, corrompem ou enviam mensagens contraditórias. Tolera f < n/3 nós maliciosos. É mais lento que Raft (3 rounds de comunicação), mas resiste a ataques.
🛡️Quando vale a pena
- •Federation com instâncias não-confiáveis — cross-org coordination
- •Plugins de terceiros executando agentes — sandbox quebrado é possível
- •Compliance crítica — auditoria precisa garantir integridade
- •Decisões financeiras / médicas — domínios de alto risco
⚠️Custo
Byzantine BFT requer n ≥ 3f+1 nós (mínimo 4 para tolerar 1 maligno). Isso significa overhead significativo. Use só quando o threat model exigir.
💫 Gossip protocol
Gossip é epidêmico: cada nó periodicamente troca informação com vizinhos aleatórios. Não há líder, não há quórum. Em troca, oferece eventual consistency — todos convergem, mas não imediatamente.
💫Características
- •Escala massiva — funciona com 100, 1000, 10000+ nós
- •Sem líder — nenhum SPOF (single point of failure)
- •Eventual consistency — convergência logarítmica O(log N)
- •Resiliente a partições — tolera redes instáveis
💡Caso de uso típico
Federation entre centenas de instalações Ruflo compartilhando padrões de aprendizado. Você não precisa que todas tenham o mesmo estado agora — basta convergir nos próximos minutos.
🔄 CRDT
Conflict-free Replicated Data Types são estruturas matemáticas onde conflitos não existem por design. Não importa a ordem das operações, todos os nós convergem para o mesmo estado.
G-Counter
Grow-only counter
Cada nó incrementa seu próprio slot. Total = soma de todos. Merge = element-wise max. Sempre converge.
OR-Set
Observed-Remove Set
Adições e remoções convivem sem conflito. Cada elemento carrega tag única. Remove só afeta tags vistas.
LWW-Register
Last-Write-Wins
Cada write carrega timestamp. Vence o mais recente. Simples mas exige clock sync (HLC ou similar).
⚖️ Quorum customizável
Quorum é o mínimo de nós que precisam concordar para uma operação ser válida. Em Ruflo é configurável: você pode exigir 2/3 dos agentes aprovando antes de aplicar uma mudança crítica.
⚖️Configurações típicas
- •Maioria simples (n/2 + 1) — Raft default
- •2/3 supermajoria — operações críticas (deploy, merge)
- •Unanimidade — change of leadership, paranoid mode
- •Weighted quorum — agentes têm pesos diferentes
📊Decision matrix
- Coding diário → Raft com maioria simples
- Deploy production → Quorum 2/3 + auditor
- Federation aberta → Byzantine BFT
- Análise massiva → Gossip + CRDT
📋Resumo do Módulo
Próximo Módulo:
3.3 - Hooks Customizados & ReasoningBank