Skip to main content
O Lerian SCR roda em um canal regulatório tarifado, e sua superfície operacional o protege.

Saúde e prontidão


GET /health responde liveness. GET /readyz responde uma entrada por dependência. O resultado do handshake serve por 20 segundos, então a prontidão nunca conecta ao BACEN por requisição. O breaker em nível de pod abre apenas quando todos os breakers por instituição estão abertos. Uma instituição com falha mantém o pod pronto e responde SCR-1002. No encerramento, /readyz retorna 503 primeiro, e o listener permanece aberto por três segundos. READYZ_DRAIN_DELAY faz override disso.

Configuração em runtime


Nove namespaces chegam a um operador em /v1/system, sob o scope scr:system:write. A tabela lista os sete que o serviço lê. scr.cors e scr.postgres também existem no catálogo. O serviço obtém suas configurações de cross-origin e de pool de conexões a partir das variáveis de ambiente. Uma mudança de nível de log entra em vigor imediatamente. Uma mudança de retenção entra em vigor na próxima varredura de expurgo. O serviço lê todos os outros namespaces quando inicia, então uma mudança ali entra em vigor na próxima reinicialização. Veja System plane. Todo parâmetro carrega limites finitos. O deadline de requisição para abaixo de 28 segundos, então uma requisição nunca sobrevive ao gateway. O limite de conexão aceita 1 ou 2.

Credenciais e rotação


O tipo de armazenamento de segredos escolhe a origem da credencial. O tipo ambiente lê o usuário e a senha a partir do ambiente de deployment. O tipo vault gerenciado os resolve por instituição, e o banco de dados mantém apenas uma referência. O tipo vault gerenciado também monta PUT /v1/scr/credential. Ele grava no vault primeiro e nos metadados depois, então uma nova tentativa reutiliza a referência. A senha nunca alcança um log, um span, ou um erro. A operação de status retorna um nome de usuário mascarado. Uma indisponibilidade do vault responde SCR-1002 e nunca aciona o breaker do canal.

Cache e retenção


O cache de resultado mantém uma entrada por instituição, índice cego do tomador e mês de referência. Cada valor carrega o envelope em repouso da linha de auditoria. Uma entrada do mês corrente vive quatro horas, uma entrada de mês fechado 720 horas. Uma entrada ilegível conta como um miss, e um deployment sem Redis dá miss sempre. O expurgo de auditoria permanece desativado até que um operador defina uma janela. Uma janela vazia não exclui nada. Com uma janela, uma varredura diária exclui linhas mais antigas em lotes limitados, e nunca as arquiva.

Métricas e rastreamento


A exportação padrão é push OTLP. Um listener de scrape do Prometheus é opt-in em um endereço loopback, 127.0.0.1:9075 por padrão. A porta da aplicação não tem nenhuma rota /metrics. Dois histogramas medem uma consulta: de ponta a ponta, e o overhead sem a chamada ao BACEN. Seus labels carregam a instituição, a flag de cache-hit, e o desfecho, nunca o tomador. Contadores cobrem códigos de decodificação desconhecidos e linhas expurgadas.

Postura de deployment


Um nome de ambiente de produção ou o modo de deployment SaaS seleciona a postura estrita. A inicialização estrita exige um modo de deployment explícito, o host do Postgres, banco de dados e usuário, e autorização sobre um endereço https. Exige a URL base do canal sobre https, e TLS no Postgres e em qualquer Redis ou broker configurado. Exige duas chaves de criptografia em repouso distintas e uma região para o vault gerenciado, e proíbe um intervalo de proxy wildcard. Uma lista de broker ou host Redis em branco recusa a inicialização, a menos que um operador declare o opt-out. O log de inicialização e o /readyz então nomeiam as proteções degradadas. Multi-tenancy precisa da URL do diretório de tenants e de uma chave de serviço. Caso contrário, um deployment atende uma instituição. Um operador aplica o esquema fora do processo de runtime. O serviço o lê e nunca o cria.