Pular para o conteúdo
Voltar aos projetos
03 2026
Automação Ciência de Dados Full-Stack

Monitor Judicial — Plataforma Multi-cliente

Lê os diários oficiais de 91 tribunais toda madrugada e entrega a cada cliente só o que é dele — em PDF, com blindagem contra falso positivo.

publicações lidas por dia
1,1 mi+
tribunais monitorados
91
ofícios entregues aos clientes
1.800+

Da dor ao resultado

Fig. 03 — Fluxo de dados 10 nós · 9 arestas
Agenda + sonda madrugada · retomada 30 min Diários eletrônicos oficiais 91 tribunais Coleta em streaming disjuntor · 2ª passada Painel + API cadastro · simulação · reenvio PostgreSQL tabelas isoladas por cliente Base pública de metadados Identificação aliases blindados Monitor pago teto de gasto Ofício consolidado novo × movimentação E-mail por cliente PDF
Origem Externo Processo Aplicação Persistência Saída
01

Antes

Mais de um milhão de publicações por dia em mais de 90 tribunais — e um nome de empresa genérico basta para mandar ao cliente um processo que não é dele.

Acompanhar as publicações judiciais de dezenas de empresas em mais de 90 tribunais, todos os dias, é inviável à mão: são mais de um milhão de publicações por dia.

Nome de empresa é ambíguo. Um alias genérico casa com o processo de outra pessoa, e o cliente recebe um ofício que não é dele — o pior erro possível aqui.

E a fonte muda sem avisar. Num dia, um campo deixou de vir e a execução terminou "OK", sem um erro no log, entregando 2 ofícios em vez de cerca de 70.

02

Como · 1/3

Construí um motor único, parametrizado por cliente, que coleta os cadernos do dia em streaming, identifica os processos pelos aliases cadastrados e consolida um ofício por processo — com tabelas, destinatários e servidor de e-mail isolados por cliente.

03

Como · 2/3

A identificação passa por uma blindagem em cascata (lista de exclusão, lista de inclusão, tamanho mínimo, termos genéricos), e o painel simula cada alias antes de ativá-lo, mostrando por que cada ocorrência seria rejeitada.

04

Como · 3/3

Em volta do motor, uma API e um painel web: cadastro de clientes, empresas e aliases, agenda própria, execução com log ao vivo, reenvio e regeração de ofício, auditoria e perfis de acesso.

05

Depois

Toda madrugada a plataforma lê os diários, separa o que é de cada cliente e entrega um ofício por processo, em PDF, no e-mail de cada um.

1,1 mi+
publicações lidas por dia
91
tribunais monitorados
1.800+
ofícios entregues aos clientes

Como ler o diagrama

A agenda dispara a coleta de madrugada e a sonda segura a execução enquanto a fonte estiver fora do ar. Os cadernos entram em streaming; a identificação usa os aliases de cada cliente; o ofício é consolidado por processo, completado com metadados quando a base responde, e sai por e-mail pelo servidor do próprio cliente. O painel cadastra, simula e reenvia. O banco desenhado como um só guarda os dados de cada cliente em tabelas isoladas.

Destaques técnicos

  1. 1 Leitura em streaming: um caderno de 300 MB que exigia 1,3 GB de memória passou a caber em 2,5 MB — editais gigantes deixaram de derrubar a coleta.
  2. 2 "Não tentou" é diferente de "falhou": fonte fora do ar vira um estado próprio, com nova tentativa automática a cada 30 minutos, em vez de uma execução que grava zero e diz OK.
  3. 3 Quando um campo deixou de vir da fonte, o número do processo passou a ser derivado dos próprios dígitos — nunca inventado —, e o reprocessamento de 114 identificações destravou 74 ofícios em 8 minutos, sem parar a execução em curso.
  4. 4 Processo novo ou movimentação? A decisão cruza três fontes e, na dúvida, trata como já conhecido: melhor não anunciar como novidade o que o cliente já sabe.
  5. 5 Enriquecimento é complemento: se a base de metadados falha, o ofício sai sem ele em vez de não sair. A fonte paga de monitoramento tem teto de gasto e nunca aparece pelo nome no documento entregue.
  6. 6 Um cliente nunca enxerga o outro: o motor se recusa a rodar se a configuração de um apontar para as tabelas de outro.