AutoflowTrilha 04 · Autoflow visão geral
Arquitetura por dentro
Você não precisa programar para implantar o Autoflow, mas precisa saber explicar ao TI do cliente quais peças existem, como os dados de um cliente ficam separados dos outros e por que o sistema é seguro. Esta lição dá essa base, em linguagem de gente.
O mapa
Clique em cada peça para ver o que ela faz, por que existe e como aparece na operação. As setas destacadas mostram com quem ela conversa.
Em uma frase: tudo passa pela API. As três telas (app, portal, console) e os sistemas externos falam só com a API; a API fala com o motor de processos (Camunda), com a identidade (Keycloak), com o banco (PostgreSQL) e com o armazenamento de arquivos (MinIO).
O Camunda é poderoso e não sabe nada sobre “organizações”, “filiais” ou “quem pode ver o quê”. Se as telas falassem direto com ele, qualquer usuário esperto poderia ler processos de outros clientes. Por isso o Camunda fica numa rede interna, sem porta pública, e a API funciona como “porteiro”: confere quem é você, qual organização está ativa, qual unidade, qual cargo — e só então repassa o pedido. Em linguagem técnica, a API é um BFF (backend for frontend).
As peças, uma por uma
| Peça | Papel | Analogia |
|---|---|---|
| API (NestJS) | Regras do Autoflow, permissões, isolamento, filas de trabalho em segundo plano | A recepção e a gerência do prédio |
| Camunda 7 | Executa BPMN e DMN: versões, processos, tokens, tarefas, timers | O motor da fábrica |
| Keycloak | Logins, senhas, MFA, convites, cargos, departamentos, SSO | A portaria com crachás |
| PostgreSQL | Dados do Autoflow + bancos do Camunda e do Keycloak | O arquivo central |
| MinIO | Os arquivos (documentos, imagens) | O almoxarifado |
| Nginx | HTTPS e direcionamento de cada endereço | A entrada do prédio |
| Apps (web, portal, super) | As telas | As salas de atendimento |
O trabalho que não precisa acontecer na hora (enviar e-mail, notificar, entregar webhook, executar etapas automáticas, atualizar métricas) vai para filas dentro do próprio PostgreSQL e é processado pela API em segundo plano. Se o envio de um e-mail falhar, o processo não volta atrás: a fila tenta de novo.
Multiempresa: como os dados de um cliente ficam separados
Uma instalação do Autoflow atende vários clientes — vários tenantsTenant — Uma organização cliente isolada dentro do Autoflow. No sistema é o "Grupo". Os dados de um tenant nunca aparecem para outro.. Todos os dados ficam nas mesmas tabelas, e cada linha carrega a marca do tenant a que pertence. A pergunta óbvia do TI do cliente é: “o que impede um bug de mostrar meus dados para outra empresa?”.
A resposta tem três camadas:
O token diz quem você é
Ao fazer login, o Keycloak entrega um “crachá digital” que contém a organização da pessoa. A API confere esse crachá em toda chamada.
A API filtra por unidade
Matriz, filial e visibilidade do cargo são aplicadas pela API em cada consulta.
O próprio banco recusa
Com RLSRLS — Row-Level Security do PostgreSQL: o próprio banco filtra as linhas por tenant. Garantia extra de isolamento entre clientes. (Row-Level Security), o PostgreSQL só devolve linhas do tenant informado na transação. A API usa um usuário de banco que não pode ignorar essa regra.
Analogia para o cliente: é um prédio de escritórios com várias empresas. Além da portaria (identidade) e da recepção (aplicação), cada sala tem fechadura própria (RLS). Mesmo que alguém da recepção erre o andar, a porta não abre.
Para órgãos públicos, essa explicação costuma ser pedida pela equipe de TI ou de controle interno. Pontos que ajudam: isolamento no nível do banco (RLS), identidade centralizada com MFA para o suporte, acesso do suporte sempre com motivo e visível na auditoria do órgão, dados pessoais mascarados por padrão no suporte, segredos de integração cifrados e chaves de API guardadas apenas como hash.
Uma ação, por dentro
O que acontece quando alguém clica em Concluir tarefa:
O que o consultor precisa saber sobre infraestrutura
- Uma instalação de produção roda em containers (Docker Compose): postgres, minio, camunda, keycloak, api, web, super, portal, com nginx na frente.
- Três endereços: o produto, o console de suporte (com lista de IPs permitidos) e o portal.
- Backup: os bancos do Autoflow, do Camunda e do Keycloak, mais o volume do MinIO. Hoje não há rotina de backup pronta no repositório pendente — combine com quem opera o servidor.
- Logs ficam nos containers, sem agregador central pendente.
- Detalhes de implantação estão na trilha 08.
Resumo
- Tudo passa pela API; o motor Camunda nunca é exposto.
- Keycloak cuida de identidade; PostgreSQL guarda dados com RLS; MinIO guarda arquivos.
- Isolamento entre clientes em três camadas: token, aplicação e banco.
- Efeitos colaterais (notificações, webhooks) vão para filas e não desfazem o negócio se falharem.