Núcleo Event-Driven

O que é o núcleo Event-Driven

O núcleo Event-Driven (EDC) é uma «espinha dorsal» da arquitetura, onde os fatos de negócios são registrados e distribuídos como eventos imutáveis, enquanto o resto da funcionalidade (leitura, integração, análise, cachê, notificação) é construído acima do fluxo desses eventos. O núcleo especifica o contrato de eventos, as regras de entrega e os invariantes de ordem/idempotação, garantindo a conectividade e a escalabilidade fracas.

A ideia chave é primeiro gravar um fato (núcleo) e depois enriquecê-lo e projetá-lo de forma independente nos modelos desejados. Isso reduz a conectividade e aumenta a resistência a falhas parciais.

Metas e propriedades EDC

A verdade dos factos é que cada evento é uma gravação imutável de «o que aconteceu».
Conectividade fraca: os produtores desconhecem os consumidores; extensão do sistema - adição de assinantes.
Escala: crescimento horizontal em partituras/topics, consumidores independentes.
Observação e auditoria: identificadores de passagem, reprodutividade, reticências e reaproximação.
Evolução controlada: versões de esquema, compatibilidade, deprecação.

Componentes arquitetônicos

1. Pneu/corretor de eventos: Kafka/NATS/Pulsar/SNS + SQS - canais, partitações, reticências.
2. Registro de esquemas: JSON Schema/Avro/Protobuf para compatibilidade e evolução.
3. Outbox/CDC: atômico do fato + publicação sem «dupla gravação».
4. Projeções/leitura (CQRS): visualizações materializadas para consultas rápidas.
5. Sagas/Orquestra: coordenação de processos de longa duração através de eventos/equipes.
6. Enriquecimento: topics individuais '.enriched '/' .derived' sem afetar o caminho crítico.
7. Traçado, logs, métricas por evento e laje.

Modelo de evento

Tipos de evento

Domain Events: factos de negócios ('payment. authorized`, `kyc. approved`).
Integration Events: Focado em sistemas externos (estáveis, lentamente mudam).
Mudar Data Capture (CDC): alterações técnicas de gravação (use para migrações/integrações).
Auditoria/Telemetry: acções, segurança, SLA.

Atributos obrigatórios (núcleo)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}

Recomendações: 'event _ id' é único globalmente; 'partition _ key' define a ordem da entidade; 'trace _ id' fornece correlação.

Semântica de entrega e idimpotência

At-least-once (padrão de muitos corretores): Os consumidores são obrigados a ser idimpotentes.
At-se-once: aceitável apenas para telemetrias secundárias.
Exactly-once: Alcançado no nível de fluxo e armazenamento através de transações/chaves/leitos idumpotentes (mais caro, necessário uma boa razão).

Modelo de Idempotação do Consumidor

Tabela de dados por 'event _ id '/' (event _ id, consumer _ id)' s TTL ≥ retenção do topic.
Upsert em vez de insert; versionagem de projeções por 'sequence '/' accurred _ at'.
Transações de transação: «viu» + alteração de estado.

Ordem e partilha

Ordem garantida dentro da partição.
Selecione 'partition _ key' para garantir que todos os eventos de uma unidade de entidade estejam na mesma partição ('user _ id', 'payment _ id').
Evite «chaves quentes»: hash com sal/baixo-chaves, se necessário para distribuir carga.

Esquemas e evolução

Aditivo-first: novos campos opcionais, proibição de mudança de tipos/semânticos sem versão maior.
Compatibilidade: BACKWARD/FORWARD no registro de esquemas; A CI bloqueia alterações incompatíveis.
Nome: 'domain. action. v{major}` (`payment. authorized. v1`).
Migrações: Publique pares de 'v1' e 'v2' em paralelo, forneça dupla radiação (dual-write via outbox), retire 'v1' após a transição.

Outbox и CDC

Outbox (recomendado para serviços de transação)

1. Em uma transação BD, preserve a gravação de domínio e o evento em outbox.
2. O pabliser de fundo lê o outbox, publica no corretor, marca «enviado».
3. Garantias: Não há «perda» de fato em baixas, não há ressincronização.

CDC (Change Data Capture)

Adequado para sistemas/migrações existentes; a fonte é o logotipo da replicação do banco de dados.
Requer filtragem/transcodificação em eventos de domínio (não transmita «crus» da tabela envolvente).

CQRS e projeções

Os comandos alteram o estado (muitas vezes sincronizado), os eventos formam projeções (asincrona).
As projeções são projetadas para consulta (busca, lista, relatório), atualizadas pelos assinantes.
Ressocialização temporária - normal: mostre um UX sustentável («os dados serão atualizados em alguns segundos»).

Sagas: coordenação de processos

Orquestra, um coordenador envia comandos e aguarda os acontecimentos.
Coreografia: os participantes respondem aos acontecimentos um do outro (simples, mas exigindo disciplina nos contratos).
Regras: compensações claras e horários, passos repetitivos, processadores idumpotentes.

Observabilidade

Trace/Span: Anote 'trace _ id '/' span _ id' através dos cabeçalhos ao gerar eventos.
Métricas: classe de consumidores, velocidade de publicação/consumo, dead-letter rate, proporção de deduções.
DLQ/parking lot: mensagens incompletas - em um top de alert separado; Garanta a readaptação.

Segurança e conformidade

Classificação de dados: o núcleo contém apenas o mínimo de PII/findado necessário (o modelo da pirâmide inversa), e os detalhes, no enriquecimento.
Assinatura/hash de atributos críticos, controle de integridade.
Criptografia in-flight e at-rest, secção de direitos por tópico/consoante (IAM/LCA).
Políticas de reticência e direitos de esquecimento são bem definidos para cada topic.

Desempenho e sustentabilidade

Backpressure: Os consumidores têm limitação de competitividade e os corretores têm quotas/limites.
Batch processamento e compressão: agrupe os registros para reduzir custos gerais.
Retrai com jitter e DLQ em vez de tentativas infinitas.
Resistência Realance: Armazene os offsets transacionalmente/externamente, acelere a partida fria com súmulos.

Modelos de evento típicos

Núcleo de pagamento

`payment. initiated. v1` → `payment. authorized. v1` → `payment. captured. v1` → `payment. settled. v1`

As falhas são 'payment. declined. v1`, `payment. refunded. v1`

Particionamento: 'payment _ id'

SLA: O núcleo de lâmina ≤ 2s p95; a idimpotência dos consumidores é obrigatória.

CUs/verificações

`kyc. started. v1` → `kyc. document. received. v1` → `kyc. approved. v1`/`kyc. rejected. v1`

PII - mínimo; detalhes do documento em 'kyc. enriched. v1 'de acesso restrito.

Auditoria/segurança

`audit. recorded. v1 'com atributos' ator ',' subject ',' action ',' accurred _ at ',' trace _ id '.
Retração/arquivamento contínuo; maior integridade (armazenamento WORM).

Antipattern

Fat Event: payload's sobrecarregado sem necessidade, vazamento de PII.
Hidden RPC através de eventos: espera por respostas sincronizadas «aqui e agora».
CDC crus para fora, estreita conectividade com a base de dados.
Não há idimpotência entre os consumidores: as duplicações produzem duplos efeitos colaterais.
Um topic geral é um conflito de interesses, uma ordem problemática, uma evolução complexa.

Implantação passo a passo da EDC

1. Mapeamento de domínio: selecione as unidades-chave e os ciclos de vida.
2. Catálogo de eventos: nomes, significados, invariantes, campos obrigatórios.
3. Esquema e registro: selecione o formato e inclua as regras de compatibilidade.
4. Outbox/CDC: Para cada produtor, defina o mecanismo de publicação dos fatos.
5. Particionamento: selecione as chaves e avalie as chaves quentes/redesenhar.
6. Idempotidade: modelo de dedução + transacionalidade dos consumidores.
7. Projeções: identifique modelos materializados e atualizações SLA.
8. Traçado, laje, DLQ, alertas.
9. Segurança/PII: classificação de dados, criptografia, LCA.
10. Hyde de evolução: política de versões, deprekate, dual-write para migração.

Folha de cheque de produção

• Cada evento tem 'event _ id', 'trace _ id', 'accurred _ at', 'partition _ key'.
• Os esquemas no registro incluem verificações de compatibilidade.
• A idimpotência dos consumidores foi implementada e testada.
• Os DLQ/parking lot e alertas foram configurados para erros de publicação/consumo.
• As projeções são reencaminhadas a partir do logs (replay) com tempo aceitável.
• Acesso limitado ao PII; payload's mínimo no núcleo.
• Os SLA são medidos e visíveis em dashboards.
• Há um plano para migrar versões de eventos e janelas de depredação.

FAQ

O que é que a EDC é diferente de «apenas pneus»?
O núcleo não é apenas um corretor, mas também um contrato de eventos, regras de ordem/idempotação, processos de evolução e observabilidade.

Podemos construir apenas com CDC?
O CDC é adequado para a integração/migração, mas os eventos de domínio expressam mais claramente o significado e sobrevivem mais às mudanças do banco de dados.

E a coerência?
Aceitamos o evolutivo consistency e projetamos OX/processos por baixo (indicadores de atualização, retraí, compensação).

Quando é preciso exactly-once?
Raramente, quando dobrar é totalmente inaceitável e impossível de compensar. Mais frequentemente, basta at-least-once + idempotidade.

Resultado

O núcleo Event-Driven transforma o fluxo de factos de negócios em fundações confiáveis do sistema. Os contratos de eventos claros, a disciplina de entrega e a observabilidade oferecem escalabilidade, resiliência e velocidade de evolução - sem as frágeis conexões sincronizadas e «tempestade» de regressão em mudanças.