Dynamic Consistency Boundary em event sourcing: o que ele resolve e onde pode complicar

O Dynamic Consistency Boundary (DCB) foi proposto por Sara Pellegrini e Milan Savic, então engenheiros da Axon, há cerca de três anos. O exemplo clássico é a matrícula de alunos em cursos: o curso tem vagas limitadas e o aluno tem um teto de matrículas. Com um stream por curso e outro por aluno, a decisão precisa de dados dos dois. Sem transação ou append atômico multi-stream, não dá para garantir as duas regras numa só operação.

No DCB, os eventos recebem tags (como student:Oskar e course:Math). O comando seleciona por tipo e tag os eventos de que precisa, decide e faz o append com a condição: falhar se algum evento que case com a consulta tiver sido gravado depois da posição lida. O event store verifica isso de forma atômica. Segundo o autor da análise, Oskar Dudycz (Emmett), a versão original, sem tags, aceitava qualquer consulta sobre eventos passados. Isso esbarra no custo de travar muito mais do que o necessário ou rastrear tudo que cada transação leu. As tags viram um compromisso: o store pré-calcula um índice por tag e tipo de evento.

A crítica central é que tags com cara de identificador de entidade funcionam como streams, só que um evento cai logicamente em vários. Elas precisam existir no momento do append, e retagging é migração. O ganho real do DCB é estreitar conflitos por tipo de evento (o exemplo é StudentEmailChanged não conflitar com a matrícula). O autor diz nunca ter visto conflitos tão frequentes a ponto de virarem problema. Quando viu, era sinal de design ruim. Ele sugere, se for preciso, labels de baixa cardinalidade (como course-enrollment) sobre streams, em vez de tags de alta cardinalidade. Também discute o argumento de que streams acumulam eventos demais: fatos repetidos, eventos artificiais só para subir versão (como SeatNextToWereTaken no exemplo do cinema) e eventos técnicos. Em banco relacional, a versão da linha do stream pode subir sem gravar evento.

Para quem modela write side em event sourcing, a leitura é que DCB resolve bem um problema técnico de contenção, mas não substitui o trabalho de modelagem. Se o event store já oferece append multi-stream transacional, vale começar por ele e só migrar para DCB se a contenção estreita for comprovada. Para quem pensa em governança e analytics, tags de alta cardinalidade também incham eventos e dificultam agrupar e filtrar por critério.