GBR: ADR-005 Persistência Hexagonal do BPE utilizando Mnesia (Zero-Cost Serialization)

• *Status:* Aceito
• *Data:* 2026-05-01

*Contexto:*

O motor de processos de negócios (gbr_bpm) operava as transições de estado da Rede de Petri puramente em memória (RAM). Em um cenário de missão crítica de telemetria corporativa (Horus Falcon 2.0), se o servidor fosse reiniciado (Crash da BEAM ou atualização), o estado de milhares de ExecutionTokens (ex: "Servidor está em estado de alerta há 5 minutos") seria perdido. A integração com bancos de dados externos tradicionais (ex: PostgreSQL) via I/O de rede e mapeamento objeto-relacional (ORM) introduziria latência inaceitável e violaria a pureza funcional da máquina de estados.

*Decisão:*

1. *Padrão de Portas e Adaptadores (Hexagonal):* Definiu-se um contrato tipado em Gleam (BpeStorage) possuindo funções injetáveis para salvar e carregar o ExecutionToken. A função matemática de transição (machine.step) agora aceita a injeção funcional desta interface de armazenamento (Option(BpeStorage)).
2. *Adoção do Mnesia (Banco de Dados Nativo do Erlang):* Criou-se a biblioteca adaptadora shared/gbr_bpm_mnesia. O Mnesia suporta transações ACID, persistência em disco (disc_copies) e é embutido diretamente na máquina virtual da BEAM, não requerendo infraestrutura externa.
3. *Serialização Nativa (Zero-Cost):* Para evitar o processamento (e latência) de transformar as estruturas de dados do Gleam (Árvores Algébricas) em JSON, a persistência utiliza a FFI em Erlang term_to_binary para gravar a representação binária exata do tipo estrito em disco, e binary_to_term para carregar.

*Consequências:*

• *Positivas:* Rastreabilidade e tolerância a falhas extremas em tempo de I/O em micro-segundos; o motor BPE permanece agnóstico em relação à infraestrutura de armazenamento, mantendo a pureza de seus testes unitários em memória.
• *Negativas/Riscos:* O Mnesia tradicionalmente sofre com gargalos de fragmentação de rede (Split-Brain) em topologias altamente particionadas e possui um limite de tamanho de banco em disco (2GB por tabela nativamente, a menos que customizado). Contramedidas futuras avaliarão a implementação de adaptadores alternativos (ex: gbr_bpm_rocksdb) se a limitação volumétrica for atingida por clientes massivos.