Arquitetura em Resumo
Um arquiteto que decide se isto entra na frente dos seus dados precisa de três respostas: do que a plataforma é feita, onde o acesso é aplicado e o que acontece em cada requisição. Elas são independentes — o formato do sistema não determina a ordem de uma requisição, e a ordem não revela o formato.
O que é a plataforma
Consumidores
- Aplicações
- Agentes de IA
- Pessoas
A Plataforma
Governança
Aplicada em toda requisição
- Isolamento
- Permissões
- Política
- Mascaramento
Evidência
- Auditoria
Superfícies
- API REST
- Endpoint Governado para Agentes
- Console
- Assistente Embutido
- Fluxo de Eventos
Resolução
- Padronizar
- Validar
- Comparar
- Consolidar
- Relacionar
Registro
- Registros Dourados
- Linhagem
- Histórico
- Relacionamentos
- Dados de Referência
Sistemas de Origem
- Plataforma de CRM
- Sistema ERP
- Banco de Dados Operacional
- Data warehouse
- Data lake
- Aplicações SaaS
- Sistema de RH
- Core Bancário
- Administração de Apólices
- Sinistros
Os sistemas de origem contribuem com registros. A camada de registro guarda um registro dourado governado por coisa do mundo real, com a linhagem, o histórico e os vínculos governados por trás dele. A camada de resolução é o que transforma a primeira na segunda. As superfícies o servem — quatro que você chama e uma que chama você quando algo muda, cada uma a mesma capacidade atrás de um protocolo diferente, nenhuma guardando regra própria.
A governança não é uma etapa pela qual os dados passam uma vez. Ela é aplicada em toda requisição, por toda superfície. Um novo consumidor a herda sem reimplementar nada, e dois consumidores não podem discordar sobre uma regra porque nenhum dos dois é dono de uma.
A auditoria fica separada das quatro camadas de aplicação porque é evidência, não aplicação. A resolução cobre as etapas que mudam um registro; receber os dados e entregá-los são as fronteiras de um lado e de outro.
Onde o acesso é aplicado
Quatro camadas independentes. Uma requisição atravessa as quatro, e cada uma pode recusar independentemente do que as outras permitam.
- RequisiçãoCom o token de quem consulta
- 2Controle de acesso por papelEste papel detém a permissão?
- 3Política por atributosPrimeira passagem — antes de existir qualquer registro
- 1Isolamento em nível de linhaAplicado pelo banco de dados, nunca pela consulta
- 3Política por atributosSegunda passagem — sobre cada registro carregado
- 4Mascaramento de camposSobre os registros sobreviventes
- Resposta
| Camada | Decide | Aplicada por |
|---|---|---|
| 1 · Isolamento em nível de linha | Quais linhas de qual organização sequer existem | O banco de dados, nunca a consulta |
| 2 · Controle de acesso por papel | Se este papel detém a permissão que a operação exige | O pipeline da requisição, antes de qualquer leitura |
| 3 · Política por atributos | Se quem consulta pode ver este registro — avaliada duas vezes | O pipeline, e de novo sobre cada registro carregado |
| 4 · Mascaramento de campos | Quais valores dentro de um registro visível são ocultados | A geração da resposta, para todo formato |
O isolamento em nível de linha é o único que nenhum erro de aplicação consegue contornar. Ele vale quando os dados são lidos, no banco de dados e não na consulta, então uma consulta que esquece de filtrar por organização devolve nada, não tudo.
A política por atributos é avaliada duas vezes, e as duas passagens veem coisas diferentes. A primeira roda antes de existir qualquer registro, então só pode julgar quem consulta, a ação e a requisição. A segunda roda com os registros já carregados e pode julgar o próprio registro — seu tipo, seus valores, com quem consulta ele se relaciona, que consentimento o cobre.
O mascaramento não é uma camada que se possa desviar. Ele roda dentro da mesma passagem que tomou a decisão de acesso, sobre o que sobreviveu a ela, para todo formato de resposta em vez de endpoint por endpoint.
Como uma requisição flui
Uma requisição pode ser recusada em três pontos — autenticação, resolução de identidade, ou a verificação de permissão e política — e, se for, termina ali. Caso contrário, ela volta de uma de duas formas.
Duas recusas diferentes, e a diferença importa. Um registro que você pediu pelo nome é recusado. Um registro que apenas aparece dentro de uma resposta — uma linha de uma lista, a outra ponta de um relacionamento, um lado de um par de correspondência — é removido da resposta, e a contagem ao lado dele diminui junto. Você nunca recebe um marcador no lugar de algo que não pode ver.
A requisição inteira é uma transação. A organização é definida nela como primeira instrução, e nada é lido antes disso.
Esse é o caminho de uma requisição de organização. A administração entre organizações segue um caminho separado, com seu próprio controle, e endpoints públicos como a autenticação pulam a resolução de identidade por completo.
Características de armazenamento
- Toda tabela de negócio guarda histórico completo de versões, sem lacunas e sem sobreposições.
- O log de auditoria é somente-adição; o próprio banco recusa atualizações e exclusões, e sua numeração é emitida pelo banco, então uma entrada faltando é detectável.
- A busca é atendida pela própria indexação de texto e similaridade do banco de dados — sem cluster de busca separado para operar ou sincronizar.
Trabalho assíncrono
Cargas em massa e recomputações rodam nos workers, não numa requisição. O trabalho é dividido em blocos que os workers reivindicam independentemente, então um worker que morre no meio perde no máximo um bloco e outro o reivindica. A reivindicação é protegida: um worker que travou e voltou não consegue sobrescrever trabalho que um colega já concluiu.
Os workers puxam trabalho, ninguém empurra para eles. A fila é uma tabela e o worker reivindica dela, então não há broker para operar nem despachante que possa perder trabalho. Eles também são separados pelo tipo de trabalho, não agrupados, então uma comparação longa não deixa uma carga sem recursos, e acrescentar capacidade a um não exige mexer no outro.