E-Docs Next-Gen Architecture: Transformação Digital em Larga Escala no Espírito Santo
1. O que é o E-Docs? Contexto e Origens
O E-Docs nasceu em 2018 como uma iniciativa do PRODEST, em parceria com SEGER, APEES e SECONT. Após uma tentativa anterior de implementar um sistema de processos eletrônicos, o governo reuniu um time focado em entregar um Produto Mínimo Viável (MVP) que permitisse, inicialmente, a autuação e o despacho de processos de forma digital.
Os resultados iniciais eram promissores. No final de 2018, quase 30 órgãos já utilizavam a ferramenta, ainda como um piloto para processos de diárias de viagens. Em 2019, o sistema tornou-se a ferramenta oficial de documentos e processos eletrônicos do Governo do Estado do Espírito Santo, e introduziu diversas melhorias, sendo destaque a captura de áudio e vídeo (substituindo os antigos CDs pendurados em pastas físicas), os selos de prioridade e dashboards de documentos e processos.
O verdadeiro ponto de inflexão ocorreu em 2020. Com a pandemia, o E-Docs tornou-se o motor que moveu o governo durante o lockdown, garantindo a continuidade do serviço público de forma totalmente remota sempre que possível, e passando assim por um crescimento exponencial de uso. O que antes era uma ferramenta de apoio passou a ser a espinha dorsal da administração pública, exigindo robustez para uma escala cuja estrutura originalmente desenhada ainda não contemplava.
Em 2021, a adoção do modelo multi-patriarca foi o marco que preparou o terreno para a expansão tecnológica, permitindo que a mesma plataforma atendesse de forma integrada tanto o Governo do Estado quanto futuramente os municípios. Esse conceito serviu como o alicerce estratégico para o ganho de escala, maximizando o investimento público ao permitir oferecer a prefeituras de diversos portes uma ferramenta robusta e de alto desempenho, eliminando a necessidade de gastos individuais com licenciamento ou desenvolvimento. Mais do que uma solução de acesso, o multi-patriarca foi o ponto de preparação essencial que permitiu ao sistema suportar a carga de múltiplos entes, criando a base estrutural que viria a ser aprimorada e potencializada pela futura arquitetura E-Docs NA.
Essa abordagem funciona como uma grande usina de energia centralizada: em vez de cada cidade construir e manter sua própria pequena geradora, todas se conectam a uma infraestrutura potente e moderna, dividindo custos e multiplicando a eficiência. No entanto, para que essa usina continuasse atendendo a todos com excelência à medida que o número de "cidades conectadas" crescia, o sistema precisou evoluir de um motor único (monolítico) para uma rede de distribuição inteligente e distribuída. Assim, o multi-patriarca estabeleceu a rede de conexão com os municípios, enquanto a arquitetura NA traria a reengenharia necessária para garantir que essa potência chegue a todos os 78 municípios de forma ágil, resiliente e escalável.
2. Desafios de Escala e a Necessidade de Reengenharia
Apesar do sucesso, o modelo inicial — baseado em uma arquitetura monolítica sustentada por servidores IIS — começou a apresentar gargalos críticos à medida que o volume de dados e acessos crescia.
Os Principais Problemas:
- Performance em Consultas: Os usuários enfrentavam lentidão maciça ao abrir caixas de processos. Processos com milhares de atos simplesmente demoravam minutos para carregar ou travavam a tela.
- Escalabilidade Rígida: Subir um novo servidor para aguentar um pico de acesso levava horas ou até dias. Em cenários onde picos de demanda podem ocorrer repentinamente (como em processos seletivos), essa demora era inaceitável.
- Alto Acoplamento e Complexidade: O sistema era um "emaranhado" de código. Uma correção em uma consulta compartilhada por várias funcionalidades frequentemente gerava bugs inesperados em outras partes do sistema.
- Dívida Técnica e Testes: A estrutura antiga impossibilitava a realização de testes automatizados de integração. Cada publicação era um risco, dependendo quase exclusivamente de testes manuais e pontuais.
- Visão de Complexidade: Por estar tudo em um único bloco, havia uma percepção errada de que o sistema era simples, quando na verdade ele escondia uma complexidade gigantesca que precisava ser revelada e gerenciada.
A missão em 2023 tornou-se clara: para levar o E-Docs aos 78 municípios do estado, era necessário abandonar o monolito e adotar uma arquitetura de serviços distribuídos. E mais: o verdadeiro desafio e a maior façanha técnica residiam no fato de que essa transição precisava ocorrer em pleno voo, sem que os usuários sentissem a mudança ou que o sistema fosse interrompido em qualquer momento.
3. A Arquitetura E-Docs NA: Design e Premissas
O projeto E-Docs NA não foi apenas uma atualização de código, mas uma mudança de paradigma baseada em Clean Code, Clean Architecture e Vertical Slice.
Pilares da Nova Estrutura:
- Arquitetura Distribuída e Responsabilidades Claras: O sistema foi quebrado em serviços independentes que se comunicam via API. Inicialmente, o foco foram quatro serviços essenciais: ENQ - Negócio Query (consultas de negócio), ECQ - Classificação Query (dados arquivísticos), EEQ - Elastic Query (buscas no elasticsearch) e EAQ - Agente Query (obtenção de servidores, grupos, setores e órgãos).
- O Conceito de Vertical Slice: Em vez de camadas horizontais rígidas, adotou-se o Vertical Slice. Cada funcionalidade (como por exemplo "Assinar um Documento") é implementada de ponta a ponta, do front-end ao banco de dados, de forma isolada, garantindo que o código seja específico para o caso de uso e não carregue dependências desnecessárias.
- Padrão CQRS (Command Query Responsibility Segregation): Para resolver os problemas de performance, separou-se a leitura (consultas) da escrita (comandos). Isso permite que, durante um pico de operações de escrita (como despachos de processos, por exemplo), o serviço de leitura continue rápido e independente, podendo ser escalado individualmente no ambiente OpenShift.
- Resiliência com Outbox Pattern: Em sistemas de alto volume, o usuário não pode esperar o processamento pesado de uma captura de documento. Com o Outbox Pattern, os comandos são enfileirados no banco e processados em background por serviços assíncronos, devolvendo o usuário à navegação do sistema quase instantaneamente.
- Result Pattern em vez de Exceptions: O uso excessivo de exceções de sistema consome muita memória RAM e gera traces pesados. O E-Docs NA utiliza o Result Pattern, onde as falhas de regra de negócio são retornadas como objetos leves, evitando quedas de aplicação por consumo excessivo de recursos durante erros comuns.
- Otimização de Infraestrutura e Startup Probes: Rodando agora em OpenShift/Kubernetes, a aplicação utiliza Startup Probes. Isso garante que o serviço só receba tráfego quando estiver totalmente "quente" (com conexões a bancos e APIs validadas), eliminando delays e erros logo após um deploy.
4. A Jornada dos Serviços: Do Negócio à Notificação
A arquitetura hoje é um ecossistema vivo. O que começou com 4 serviços em 2023, evoluiu para uma malha complexa que inclui:
- Negócio Base: Contém as regras fundamentais que todos os outros serviços compartilham, como permissões de papéis.
- Agente Query & Cache Permanente: Montar um "Agente" (servidor + cargo + lotação) exigia consultar constantemente três API’s diferentes (Acesso Cidadão, Lotação e Organograma). O E-Docs NA implementou um cache permanente que reduziu drasticamente o tempo de resposta, montando o perfil do usuário em milissegundos.
- Usuário Manager: Criado para gerenciar delegações de acesso, papéis preferenciais e gestão de favoritos, retirando essa carga do serviço principal de negócio.
- Notificação Composer: Um serviço dedicado exclusivamente para a lógica da geração de notificações e ao envio de e-mails e sininho.
5. Estratégias para uma Migração Controlada e Responsável
Migrar funcionalidades de um sistema crítico e monolítico para uma arquitetura distribuída exige mais do que apenas código novo; exige uma estratégia de implantação que minimize riscos e garanta a continuidade do negócio. No projeto E-Docs NA, a transição é pautada por soluções que permitem uma migração "viva" e segura.
1. Feature Flags: O Termômetro da Migração
A principal ferramenta para garantir uma migração responsável é o uso de Feature Flags. Essa técnica permite que a nova implementação e a anterior coexistam no ambiente de produção. Através de um mecanismo de permissões, podemos:
• Validar Funcionalidades em Grupos Pequenos: Inicialmente, a nova versão é liberada apenas para usuários internos ou grupos restritos para coletar feedbacks rápidos.
• Escalabilidade Gradual por Carga: Para mitigar problemas de performance, a ativação é feita por grupos de órgãos (pequenos, médios e grandes) até atingir todo o governo.
• Rollback Imediato: Se um erro for detectado em produção, basta desativar a flag para que todos os usuários retornem instantaneamente à versão estável anterior, sem necessidade de novos deploys.
Essa estratégia funciona como a inauguração gradual de uma nova rodovia construída ao lado de uma antiga: inicialmente, libera-se apenas uma faixa para poucos veículos testarem a segurança e o asfalto; conforme a estrutura prova suportar o peso, abrem-se mais faixas para caminhões e ônibus, até que todo o tráfego seja desviado para a via moderna e a antiga possa ser desativada.
2. Observabilidade e Telemetria em Tempo Real
Uma migração responsável não é feita no escuro. O uso de ferramentas de rastreabilidade ponta a ponta, como o Dynatrace, permite monitorar cada requisição entre os microsserviços. Isso possibilita identificar gargalos de performance — como uma query de banco lenta ou um delay de resposta entre serviços — antes mesmo que o usuário final perceba o problema.
6. O Sistema em Números: Uma Operação de Gigante
Para entender a magnitude do E-Docs, é preciso olhar para os dados. O sistema hoje não é apenas um repositório, mas um gigante de Big Data governamental.
- Requisições Diárias: Os novos serviços processam mais de 29 milhões de requisições por dia.
- Volume de Documentos: São mais de 150 milhões de documentos capturados e 440 milhões de páginas em PDF armazenadas.
- Assinaturas Eletrônicas: Foram realizadas 96 milhões de assinaturas ao longo da história do sistema.
- Armazenamento Massivo: O ambiente de produção gerencia mais de 100 Terabytes de dados, incluindo 56 TB em arquivos (MinIO) e 40 TB de logs de auditoria.
- Infraestrutura: O sistema opera com 184 vCPUs e quase 1 Terabyte de RAM distribuídos entre servidores, bancos de dados e clusters de busca.
- Expansão Municipal: Atualmente, 24 prefeituras já utilizam o sistema, com a meta de atingir 40 até o próximo ano de 2026, democratizando o acesso ao processo eletrônico para municípios de todos os tamanhos.
Conclusão
A evolução para o E-Docs NA mostra que a modernização tecnológica na gestão pública é um caminho sem volta. Ao adotar padrões de mercado e uma infraestrutura resiliente, o E-Docs garante que o Espírito Santo continuará na vanguarda da eficiência governamental. Mais do que uma arquitetura, o E-Docs NA é uma prova de que a engenharia de software de alta qualidade pode (e deve) estar a serviço do cidadão.
Curiosidade Técnica: Uma requisição para montar a caixa de encaminhamento no E-Docs NA passa por cinco serviços diferentes (Web, Negócio Query, Negócio Base, Elastic Query e Agente Query) e, graças à otimização do cache e do Redis, todo esse processo de montagem de dados formatados leva, em média, apenas 70 milissegundos.
Sobre os Autores
Roberto Marconi : Supervisor de sistemas e Tech Lead, lidera a evolução estratégica e tecnológica do E-Docs desde sua concepção em 2018. É responsável por guiar a jornada de modernização e garantir que o sistema suporte a crescente demanda de processos eletrônicos no estado.
Luciano Lorencini : Coordenador de desenvolvimento e Software Engineer, lidera a concepção de novas funcionalidades e a implementação de melhorias contínuas na arquitetura da plataforma.
Kassiane Pretti : Software Engineer e líder técnica do E-Docs NA Architecture, conduz a transição do sistema para uma arquitetura distribuída e escalável. Especialista na reengenharia de funcionalidades complexas, aplicando padrões de Clean Architecture, Clean Code e Testes Automatizados para maximizar a performance e manutenibilidade.
#Tecnologia #SoftwareArchitecture #GovernoDigital #CleanArchitecture #EDocs #Prodest #EspíritoSanto