Aparência
Tecnologias e decisões
Esta página apresenta cada tecnologia da plataforma, o papel dela e o motivo da escolha. As decisões seguem três princípios de arquitetura:
- Neutralidade de nuvem. Só a camada de infraestrutura muda entre provedores; tudo acima dela roda igual em qualquer cluster Kubernetes. A instituição escolhe a nuvem, e ficar presa a um provedor não é aceitável para bancos e seguradoras.
- Paridade regulatória entre ambientes. Sandbox e produção podem diferir em conta, porte e orçamento, mas nunca em segurança, autenticação, perfil FAPI, identidade, rede, TLS ou evidências.
- A instituição no controle. A orquestração roda com as credenciais da própria instituição. A Finnest não hospeda a operação nem guarda dados regulatórios.
Aplicação
| Tecnologia | Papel |
|---|---|
| Bun 1.4 | Runtime de todos os serviços e da CLI |
| TypeScript 6 | Linguagem de toda a plataforma, verificada pelo compilador nativo do 7 |
| Hono 4 | Framework HTTP dos serviços |
| Zod 4 | Contratos de dados e de API |
| Drizzle ORM | Acesso a dados e migrações |
Por que Bun. Um único binário substitui empacotador, executor de testes e gerenciador de pacotes. A versão 1.4 trouxe imagens de serviço menores (−19%), um interpretador 9% mais rápido e compatibilidade com distribuições Linux mais antigas para a CLI. Para a CLI também foram avaliados Deno, Node SEA e reescrever em Go ou Rust; manter Bun preservou uma única base de código.
Por que Hono. Segue o padrão fetch da Web, tem vazão cerca de três vezes maior que o Express e suporte nativo ao Bun. Toda rota é declarada com contrato OpenAPI tipado, que gera a documentação das APIs.
Por que contratos Zod. Cada endpoint tem esquemas nomeados de requisição e resposta, separados dos esquemas de domínio, e os dados externos são validados uma única vez na entrada. A especificação OpenAPI é gerada a partir desses contratos, e qualquer divergência falha a integração contínua.
Dados e eventos
| Tecnologia | Papel |
|---|---|
| PostgreSQL gerenciado (Aurora na AWS, Flexible Server na Azure) | Fonte de verdade: dados de negócio, consentimentos, auditoria e outbox |
| Redis gerenciado (ElastiCache na AWS, Azure Managed Redis) | Cache, limites de requisição e distribuição de feature flags |
| NATS JetStream | Entrega interna de eventos |
| CloudEvents 1.0 | Formato dos eventos |
Por que PostgreSQL. Um único motor atende operações transacionais e séries temporais, sem adicionar outros bancos. Cada serviço tem o próprio schema.
Por que banco gerenciado. Nenhuma regra do Open Finance, do Open Insurance, do BCB ou da SUSEP exige banco dentro do cluster. O banco gerenciado entrega backup, recuperação para um ponto no tempo e alta disponibilidade operados pelo provedor, e existe nas regiões sa-east-1 e Brazil South. Operadores de banco dentro do cluster (CloudNativePG, Redis Operator) foram avaliados e descartados; o banco dentro do cluster também era o maior item de custo.
Por que outbox transacional com NATS JetStream. Publicar um evento depois de gravar no banco pode perder o evento se o processo cair entre as duas etapas. Com o outbox, o evento é gravado na mesma transação da operação e entregue depois, com entrega pelo menos uma vez e estado de negócio consistente. O NATS foi preferido ao Kafka por ser mais simples de operar e ter vazão suficiente para o volume de eventos regulatórios. Cache e entrega de eventos ficam separados de propósito: Redis para um, NATS para o outro.
Identidade e gateway
| Tecnologia | Papel |
|---|---|
| Keycloak 26 | Servidor de autorização (realms Open Finance, Open Insurance e administração) |
| Camada FAPI da Finnest | Validações do perfil FAPI-BR na borda de cada serviço |
| Kong Gateway 3.10 | Terminação mTLS com ICP-Brasil e roteamento das APIs |
| Better Auth | Identidade dos operadores humanos no Power Admin e na CLI |
Por que Keycloak. Tem políticas de cliente FAPI nativas, sem extensões Java; realms separados dão emissores independentes para cada ecossistema; e é um servidor de autorização de referência na certificação FAPI da OpenID Foundation. Foram descartados:
- Authentik: sem FAPI nativo, DCR limitado e sem CIBA;
- Ory Hydra: sem motor de políticas FAPI, sem CIBA e sem múltiplos realms;
- Auth0, Okta e Cognito: SaaS, o que contraria a neutralidade de nuvem, e preço por usuário ativo;
- WSO2: exige licença premium para os recursos necessários.
Por que três camadas de segurança FAPI. O Kong cuida do transporte (mTLS com ICP-Brasil e restrição de cifras). O Keycloak cuida do estado OAuth/OIDC. Uma biblioteca própria verifica, na borda de cada serviço, as invariantes do perfil: cadeia ICP-Brasil, SSA, jti, acr e vínculo do token ao certificado. Os serviços nunca dependem diretamente do Keycloak, então trocar o servidor de autorização afetaria um único pacote.
Por que identidade separada para operadores. Operadores humanos e clientes do ecossistema regulado têm ciclos de vida e modelos de ameaça diferentes. O Better Auth roda como biblioteca, sem processo extra, e oferece login por dispositivo, papéis por organização, passkeys, TOTP e SSO.
Plataforma
| Tecnologia | Papel |
|---|---|
| Kubernetes (EKS e AKS) e Helm | Execução e empacotamento da aplicação |
| Pulumi com Automation API | Criação da infraestrutura de nuvem e do runtime, executada pela CLI |
| Cilium com Gateway API | Rede do cluster, políticas de rede e entrada de tráfego |
| cert-manager | Emissão e renovação automáticas dos certificados TLS públicos |
| External Secrets Operator | Sincronização dos segredos do cofre da nuvem para o cluster |
| Kyverno | Políticas de admissão para os recursos criados pelos charts |
| KEDA e Karpenter (AWS) | Escala de serviços e de nós |
| Pulumi CrossGuard | Políticas de infraestrutura como código, avaliadas em todo deploy |
Por que Kubernetes e Helm. Um único conjunto de artefatos roda em qualquer nuvem. Um chart guarda-chuva atende todos os formatos de implantação, e módulos e tamanhos são ativados por configuração.
Por que Pulumi. A infraestrutura é descrita em TypeScript, a mesma linguagem da plataforma, e o Automation API permite que a própria CLI conduza o deploy, sem ferramentas extras na estação do operador.
Por que Cilium gerenciado pela Finnest nas duas nuvens. Mesmo na Azure, a plataforma instala o próprio Cilium em vez de usar o Cilium gerenciado pelo AKS. Assim, Gateway, rotas e políticas de rede se comportam igual na AWS e na Azure.
Operadores de infraestrutura. Cada operador (cert-manager, External Secrets, DNS) recebe uma identidade de nuvem própria e mínima (IRSA na AWS, Workload Identity na Azure).
Nuvens suportadas
A plataforma expõe apenas as nuvens com garantia completa de funcionamento: AWS e Azure. Outras nuvens só serão oferecidas depois de passar pelo mesmo nível de garantia.
Entrega e cadeia de suprimentos
| Tecnologia | Papel |
|---|---|
| GitHub Actions | Build, testes e publicação |
| cosign | Assinatura de imagens, binários da CLI e chart |
| SLSA e SBOM CycloneDX | Proveniência e inventário de cada artefato |
| Trivy | Varredura de vulnerabilidades antes da publicação |
Por que pipeline nativo do GitHub Actions. A orquestração anterior, baseada em Dagger, deixava o caminho comum muito mais lento; o build das imagens levava mais de 24 minutos por repetir a preparação em cada job. O pipeline atual roda direto nos executores.
Por que assinatura keyless e proveniência. A assinatura usa a identidade OIDC do GitHub, sem chave de longa duração para proteger. Cada artefato tem origem verificável e inventário de componentes, o que acelera a resposta a vulnerabilidades e as auditorias. A CLI verifica a assinatura dos bytes baixados antes de instalar ou atualizar.
Observabilidade
| Tecnologia | Papel |
|---|---|
| OpenTelemetry | Traces, métricas e logs de todos os serviços |
| Grafana Alloy | Coletor de telemetria na implantação |
Por que OpenTelemetry. A telemetria sai em formato aberto (OTLP), e a instituição escolhe o backend: Datadog, New Relic, Honeycomb, Grafana ou uma solução própria. A plataforma não impõe ferramenta de observabilidade.
CLI e operação
Por que a orquestração roda na estação da instituição. Toda a execução acontece localmente, com as credenciais de nuvem da instituição. A Finnest não hospeda orquestração e não guarda dados regulatórios. Um modelo de cliente fino, com a orquestração na Finnest, foi descartado.
Por que um único binário com três modos. A mesma CLI funciona sem interface (para pipelines), com terminal interativo e com o painel (cockpit). Toda execução tem saída JSON versionada, códigos de saída estruturados e evidência gravada em disco, para automação e auditoria.
Por que licença offline. A licença é um token assinado (Ed25519), verificado na inicialização sem chamadas de rede.
Feature flags. PostgreSQL, Redis e cache em memória, com invalidação em segundos. Serviços como o LaunchDarkly foram descartados por custo e por não poderem rodar na infraestrutura da instituição.
Console de administração
O Power Admin é uma aplicação React, construída com Vite e TanStack, servida por nginx sem privilégios. Ele roda como contêiner dentro do cluster, atrás do mesmo Gateway, em admin.<domínio>, para manter a paridade entre AWS e Azure.