ORKEN

Problema

Uma condição de filtro esquecida numa consulta é o bug mais caro possível em um sistema multiempresa: mostra dado de um cliente para outro, passa por revisão de código sem chamar atenção e não quebra teste nenhum.

Solução

Cinco camadas. O token carrega a empresa; um middleware valida o vínculo entre usuário e empresa e resolve o contexto antes de qualquer consulta; um filtro global aplicado a toda entidade de negócio adiciona automaticamente a condição de empresa; um interceptor de salvamento injeta a empresa nos inserts e lança se alguém tentar gravar em nome de outra ou alterar a empresa de uma linha existente; e os testes de integração criam duas empresas em todo caso que envolva isolamento. Desligar o filtro é proibido no código de aplicação.

Por que foi feito assim

Fazer o isolamento depender de cada desenvolvedor lembrar não escala com o time nem com a superfície do produto. Movendo a regra para os pontos por onde toda consulta e todo salvamento passam obrigatoriamente, o caminho errado deixa de ser possível — e a violação vira exceção alta, não linha silenciosa no resultado.

Problema

Um limitador de login configurado como um balde único e global significa que algumas tentativas erradas de uma pessoa consomem a cota de todo mundo. É negação de serviço acidental — e um vetor trivial para quem queira derrubar o login do sistema inteiro de propósito.

Solução

O limitador particiona por identidade do solicitante, de modo que o contador de um não interfere no do outro.

Por que foi feito assim

A partição por identidade contém tentativas abusivas sem consumir a cota de usuários legítimos.

Problema

Provedores de pagamento reentregam eventos — por retry, por timeout de resposta, por reprocessamento do lado deles. Processar o mesmo evento duas vezes libera módulo em duplicidade ou registra cobrança repetida.

Solução

O identificador de cada evento processado com sucesso é registrado numa tabela própria. Antes de processar, o sistema consulta; depois de processar, insere.

Por que foi feito assim

A reentrega faz parte do contrato de entrega ao menos uma vez. O receptor registra o identificador do evento para garantir idempotência.

Problema

Lançar movimento financeiro à mão é lento, e a fonte da informação costuma ser um comprovante ou um texto solto — não um formulário.

Solução

Um pipeline que separa duas coisas que costumam ser confundidas: extração ("o que está escrito no documento") e interpretação ("o que isso significa dentro desta operação"). A interpretação produz uma sugestão em que cada campo carrega a origem da sugestão, e nada vira lançamento sem confirmação. Correções do usuário realimentam um perfil de memória por empresa.

Por que foi feito assim

Separar extração de interpretação permite trocar o extrator sem tocar em regra de negócio, e testar a regra sem depender de um documento real. A confirmação humana impede que um erro de interpretação vire lançamento contábil antes da revisão.

Problema

O diário de obra registra a condição do tempo por turno, e é esse registro que sustenta pedido de prorrogação de prazo por chuva. Preenchido de memória na sexta-feira, não sustenta nada.

Solução

Integração com um serviço público de meteorologia, que preenche a condição do dia a partir da coordenada da obra no momento do lançamento.

Por que foi feito assim

É dado de terceiro, com data, e não depende da lembrança de ninguém — que é exatamente o que dá valor probatório ao registro. Não há modelo nem inferência envolvida: é uma consulta a uma fonte externa. A integração consulta uma fonte externa; não há modelo nem inferência envolvidos.