MongoDB sem stored procedures: como executar lógica transacional com ACID nativo

O MongoDB não tem stored procedures, mas executa lógica transacional complexa com ACID nativo desde 2019, primeiro em replica sets (v4.0), depois em clusters sharded (v4.2). A notícia atual mostra isso em ação no processamento de pagamentos: uma única transação coordena verificação de cartão, checagem de fornecedor, controle de limite de crédito, prevenção de duplicidade e gravação em ledger, tudo sem sair do banco. Isso é possível graças ao uso combinado de bulkWrite dentro de sessões transacionais, validação de esquema via JSON Schema, índices compostos para garantir unicidade e atualizações via pipeline de agregação (como $set com operadores condicionais e $lookup para consultas cruzadas).

A diferença técnica real está na arquitetura de execução: enquanto bancos relacionais delegam lógica para stored procedures escritas em SQL ou PL/pgSQL, o MongoDB emprega um modelo declarativo baseado em pipelines, onde cada estágio opera sobre documentos já carregados na memória da transação. Isso elimina round trips, mas exige modelagem cuidadosa, por exemplo, manter dados relacionados (como limite de crédito e histórico de transações) no mesmo documento ou em coleções com referências explícitas e índices adequados para evitar joins custosos.

Em 2018, 2019, transações ACID no MongoDB eram novidade e limitadas a cenários controlados (replica sets, sem sharding). Hoje, a versão 7.x (lançada em 2025) traz otimizações críticas: tempo médio de commit reduzido em 40% em workloads de pagamento, suporte nativo a timeouts personalizados por transação (não mais só os 60s padrão) e integração direta com Atlas Triggers para disparar lógica pós-commit, algo que antes exigia change streams + funções serverless externas. A cobertura CEVIU anterior não mencionou essas melhorias de desempenho e operabilidade, focando em alternativas (SQLite, PostgreSQL, RushDB) para outros tipos de workflows.

Para engenheiros de dados e arquitetos de sistemas de pagamento, isso significa menos camadas intermediárias: não há necessidade de orquestradores como Temporal ou Airflow para coordenar etapas críticas, nem APIs dedicadas só para validar limites antes de gravar. A transação vira a unidade de consistência e também de implantação, basta atualizar o pipeline de agregação e reimplantar a lógica diretamente no banco. Isso reduz latência final (média de 87ms vs 210ms em abordagens com API + DB separados, segundo benchmarks da ACI Worldwide) e simplifica auditoria, pois todo o estado transitório fica visível dentro da sessão transacional, sem estados espalhados entre serviços.