Arquitetura e segurança
Três peças, dentro da sua rede.
Escrito para quem vai aprovar a entrada da plataforma no ambiente — TI, DBA e segurança.
Portal
A aplicação web onde se cadastra, valida e agenda. Não executa processo.
Executor
Serviço em container que sonda a fila e executa as rotinas. Pode haver vários, em máquinas diferentes. (No código e nos logs ele aparece como Worker — é o mesmo componente.)
HUB de orquestração
Guarda definições, permissões, a fila e o histórico. É o único canal entre portal e executor — e roda sobre o banco que você escolher.
O HUB
Por que o componente central é um banco de dados.
É decisão de arquitetura, não economia. Vale explicar, porque quem avalia costuma esperar um serviço próprio no lugar.
Nada a mais para operar
Sem fila de mensagens para instalar, monitorar, atualizar e proteger. Numa operação de empresa média isso não é economia de infraestrutura — é economia de gente.
Consistência transacional
A fila e o dado vivem na mesma transação. Um broker traria escrita dupla e o problema de entrega exatamente-uma-vez; este desenho não tem esse problema.
Recuperar é uma consulta
Execução interrompida por queda é encontrada e reenfileirada lendo uma tabela — não reprocessando um log de eventos.
Seu DBA já sabe operar
Backup, monitoramento, réplica e alta disponibilidade do HUB são os procedimentos que a sua casa já tem, na ferramenta que ela já usa.
Onde o HUB roda
No seu servidor, ou numa nuvem gerenciada. Você decide.
É a mesma instalação — muda uma linha de configuração. A escolha tem consequência, então ela está escrita aqui, e não no rodapé do contrato.
HUB no seu servidor
Dado e controle ficam inteiramente dentro da sua rede.
Ganha: funciona sem internet nenhuma, e nada sai da casa.
Assume: a alta disponibilidade do HUB é a que você montar.
HUB em nuvem gerenciada
Azure SQL, Amazon RDS, Cloud SQL ou Oracle Autonomous — são os mesmos providers, por connection string.
Ganha: a alta disponibilidade do HUB passa a ser a do seu provedor.
Assume: os executores precisam de link até ele — deixa de funcionar offline.
Os executores continuam onde o trabalho está: junto do ERP legado, do Firebird da filial, do compartilhamento de arquivos. É o HUB que pode subir para a nuvem — não a execução.
Segurança
Onde o segredo mora.
Credenciais cifradas
Senhas de banco e de SMTP são cifradas com as chaves de proteção da instalação. Não há tela que as mostre depois de gravadas, e elas nunca aparecem inteiras em log.
Injeção sem senha no código
O script recebe conexão e credencial como variável de ambiente. Nada de senha em texto dentro do processo — e o que a etapa recebe é uma declaração explícita, conferida na hora de salvar.
Autorização em camadas
5 perfis de usuário, vínculos por processo, tags restritas e modo oculto. A checagem é no servidor, em cada ação — esconder o botão nunca foi considerado proteção.
Importação controlada
Importar um pacote faz entrar código que o executor executa. Por isso é um item por vez, com limites de tamanho e recusa de conteúdo malicioso — nunca em lote.
Operação
O que roda sozinho, e onde.
| Rotina | Frequência | Onde roda |
|---|---|---|
| Execução da fila | a cada 5 s | todos os executores |
| Disparo por agenda | a cada 30 s | todos os executores (uma vez só) |
| Sinal de vida | a cada 1 min | todos os executores |
| Limpeza de dados de execução | a cada 1 h | todos os executores |
| Purga de histórico e métricas | meia-noite local | só o executor principal |
| Expurgo da lixeira | a cada 6 h | só o executor principal |
Continuidade
O portal fora do ar não para as suas rotinas.
É consequência direta da arquitetura: a fila mora no banco e quem executa são os executores, processos separados. Se o portal cai às 3h da manhã, as agendas continuam disparando e a fila continua sendo consumida — você perde a tela, não a operação.
Executores
Vários no mesmo banco, nativamente. A disputa pela fila é resolvida no próprio banco, então executor pode entrar e sair sem coordenar nada — e a execução interrompida por uma queda é recuperada quando ele volta.
Nativo — nada a configurar além de subir outro executor.
Banco
É o seu. Use a alta disponibilidade que você já tem — cluster, réplica ou serviço gerenciado. A plataforma não se mete no assunto.
Seu padrão — 5 bancos suportados como banco de controle.
Portal
Uma instância por instalação é a topologia testada. A continuidade vem da infraestrutura que você já opera: cluster de hipervisor ou orquestrador de container reinicia o portal em outro nó, como faz com qualquer outra aplicação sua.
Sua infraestrutura — Proxmox, Hyper-V, VMware, Kubernetes.
O que não existe é escala automática: a plataforma não sobe nem derruba executor sozinha conforme a carga. Quantos executores rodam é decisão sua, e o custo não muda com o volume.