Guia: escalabilidade e performance em banco digital

Última atualização: 22 de julho de 2026

Principais lições deste artigo

• Escalar por domínio: arquiteturas de microsserviços por domínio permitem escalar Pix, cartões e crédito de forma independente, mantendo latência e conformidade em picos de demanda.

• Isolar picos de volume: processamento assíncrono com Kafka ou RabbitMQ, aliado a dead-letter queues e idempotency keys, isola picos de volume e mantém os SLOs estáveis.

• Reduzir latência em banco de dados: separação de leitura e escrita, sharding e cache em Redis reduzem latência e suportam crescimento de transações sem comprometer a consistência regulatória.

• Proteger disponibilidade: auto-scaling multi-AZ, observabilidade completa com SLOs e chaos engineering preservam a disponibilidade e reduzem o MTTD em ambientes críticos.

• Facilitar conformidade e migração: automatizar relatórios regulatórios e migrar de Banking as a Service para Core Banking com licença própria se torna mais simples e seguro com a infraestrutura da Celcoin: saiba mais.

1. Arquitetura de microsserviços por domínio

Arquiteturas bancárias modernas decompõem o núcleo em funções de negócio discretas, como gestão de contas, processamento de pagamentos, detecção de fraude, relatórios regulatórios e originação de crédito, com cada serviço possuindo seus dados e expondo funcionalidade via APIs. Esse modelo permite que cada domínio evolua e escale no seu próprio ritmo. Separar Pix, cartões e crédito em serviços independentes permite escalar cada domínio conforme a demanda específica.

Passos de implementação:

1. Mapear bounded contexts de negócio: Pix, cartões, crédito, KYC, notificações e relatórios regulatórios.

2. Definir contratos de API para cada serviço antes de iniciar o desenvolvimento.

3. Garantir que cada serviço possua seu próprio banco de dados, seguindo o padrão database per service.

4. Implementar um API Gateway centralizado para autenticação, rate limiting e roteamento.

5. Adotar service mesh, como Istio, para comunicação segura entre serviços com mTLS.

6. Versionar APIs com retrocompatibilidade para evitar breaking changes em produção.

7. Aplicar o padrão strangler fig para extrair domínios de sistemas legados sem interromper o serviço.

Checklist de microsserviços por domínio:

• Bounded contexts mapeados e documentados

• Database per service implementado

• API Gateway configurado com autenticação e rate limiting

• Service mesh com mTLS ativo

• Versionamento de APIs definido

• Pipeline de CI/CD independente por serviço

• Padrão strangler fig aplicado para módulos legados

2. Processamento assíncrono com Kafka ou RabbitMQ

Arquiteturas orientadas a eventos desacoplam produtores e consumidores de eventos de pagamento usando message brokers duráveis e schemas de eventos com compatibilidade retroativa. Essa abordagem aumenta elasticidade e resiliência sob variações de carga. Em fluxos de Pix, essa estratégia impede que picos de volume pressionem diretamente serviços downstream.

Passos de implementação:

1. Definir tópicos por domínio, como pix.initiated, pix.confirmed, card.authorized e notification.send.

2. Configurar retenção de mensagens com durabilidade garantida, com replicação mínima de três brokers.

3. Implementar idempotency keys em todos os consumidores para evitar processamento duplicado.

4. Adotar dead-letter queues para mensagens com falha de processamento.

5. Monitorar consumer lag como métrica primária de saúde do pipeline assíncrono.

6. Versionar schemas de eventos com Avro ou Protobuf para manter compatibilidade entre versões.

7. Testar comportamento de backpressure com simulação de consumidores lentos.

Checklist de processamento assíncrono:

• Tópicos por domínio definidos e documentados

• Replicação mínima de três brokers configurada

• Idempotency keys implementadas em todos os consumidores

• Dead-letter queues configuradas

• Consumer lag monitorado com alertas

• Schemas versionados com Avro ou Protobuf

• Testes de backpressure executados

3. Separação de leitura e escrita e sharding em bancos de dados

Uma estratégia híbrida de dados combina caches em memória para operações de baixa latência, logs append-only para captura de eventos e bancos relacionais ou SQL distribuídos para consistência forte. Essa combinação atende fluxos com requisitos diferentes de consistência.

Passos de implementação:

1. Separar instâncias de escrita, como primário, e leitura, como réplicas, para workloads transacionais, criando a base de distribuição de carga.

2. Sobre essa separação, implementar Redis como camada de cache para consultas de saldo e limites de Pix, reduzindo a pressão sobre as réplicas de leitura.

3. Para escalar além da capacidade de uma única instância, definir partition keys de sharding por domínio de negócio, como cliente, produto ou região.

4. Adotar eventual consistency com sagas e compensating transactions para transações distribuídas.

5. Manter log imutável de eventos como fonte de verdade para auditoria regulatória.

6. Configurar Change Data Capture, ou CDC, para sincronização entre sistemas durante migrações.

7. Validar reconciliação automática entre réplicas com frequência mínima horária.

Checklist de banco de dados:

• Read replicas configuradas e testadas

• Cache Redis implementado para consultas de alta frequência

• Partition keys definidas por domínio de negócio

• Sagas implementadas para transações distribuídas

• Log imutável de eventos ativo

• CDC configurado para migrações

• Reconciliação automática validada

4. Auto-scaling em nuvem com multi-AZ

Deployments active-active em múltiplas zonas de disponibilidade formam a base para workloads bancários críticos e reduzem o risco de interrupções de serviço por falhas únicas de infraestrutura. Esse padrão também reduz a probabilidade de incidentes reportáveis no DORA.

Passos de implementação:

1. Configurar Horizontal Pod Autoscaler, ou HPA, com métricas customizadas de transações por segundo.

2. Distribuir workloads em pelo menos três zonas de disponibilidade por região.

3. Implementar active-active com balanceamento de carga entre zonas de disponibilidade.

4. Definir políticas de scale-out antecipado baseadas em calendário, como datas de pagamento e Black Friday.

5. Adotar serviços stateless para facilitar escalonamento horizontal sem dependência de estado local.

6. Configurar circuit breakers para isolar falhas de serviços dependentes.

7. Testar failover entre zonas de disponibilidade com simulações programadas antes de datas de alto volume.

Checklist de auto-scaling multi-AZ:

• HPA configurado com métricas de negócio

• Mínimo de três zonas de disponibilidade ativas por região

• Active-active com balanceamento de carga

• Políticas de scale-out antecipado por calendário

• Serviços stateless validados

• Circuit breakers configurados

• Failover entre zonas de disponibilidade testado periodicamente

5. Observabilidade completa

Plataformas de pagamento maduras tratam confiabilidade como funcionalidade de produto e definem SLOs e error budgets que orientam decisões de engenharia. Logs, métricas, tracing distribuído e SLOs formam os pilares da observabilidade em ambientes bancários.

Passos de implementação:

1. Implementar tracing distribuído com OpenTelemetry em todos os serviços críticos.

2. Centralizar logs estruturados com correlação por transaction_id e customer_id.

3. Definir SLOs para fluxos críticos, como autorização de Pix, captura de cartão e liquidação.

4. Configurar alertas baseados em error budgets, e não apenas em thresholds fixos.

5. Criar dashboards por domínio com latência P95 e P99 visíveis em tempo real.

6. Integrar métricas de negócio, como volume de Pix e taxa de falha, aos painéis de engenharia.

7. Estabelecer runbooks automatizados para os alertas mais frequentes.

Checklist de observabilidade:

• Tracing distribuído com OpenTelemetry implementado

• Logs estruturados centralizados com correlação

• SLOs definidos para fluxos críticos

• Alertas baseados em error budgets

• Dashboards com latência P95 e P99

• Métricas de negócio integradas

• Runbooks automatizados para alertas recorrentes

6. Testes de carga, estresse e chaos engineering

Experimentos de chaos engineering em produção em sistemas que processam Pix, transferências e autorizações a milhares de transações por segundo já demonstraram redução de 73% no MTTD e exposição de vulnerabilidades ocultas. Casos práticos de bancos brasileiros ilustram esses ganhos. Em paralelo, plataformas de pagamento maduras mantêm latência de autorização abaixo de 2 segundos no P95 e entrega de webhooks abaixo de 30 segundos no P99.

Passos de implementação:

1. Usar Gatling, k6 ou Apache JMeter para testes de carga com usuários simultâneos.

2. Testar em progressão de 2, 10, 50 e 100 usuários concorrentes para identificar o ponto de ruptura.

3. Executar soak tests com carga sustentada por 24 horas para detectar memory leaks.

4. Implementar chaos engineering com falhas injetadas em conectividade, latência e indisponibilidade de dependências.

5. Realizar GameDays multidisciplinares com cenários realistas de falha antes de datas críticas.

6. Validar idempotência enviando requisições duplicadas com o mesmo Idempotency-Key.

7. Documentar rollback criteria e executar pelo menos três dress rehearsals completos antes de migrações.

Checklist de testes de resiliência:

• Testes de carga com ferramentas de requisições simultâneas

• Progressão de carga de 2 a 100 usuários concorrentes

• Soak tests de 24 horas executados

• Chaos engineering com falhas injetadas em produção ou staging

• GameDays multidisciplinares realizados

• Idempotência validada com Idempotency-Key duplicada

• Três dress rehearsals documentados antes de migrações

Conheça a infraestrutura da Celcoin para escalar sua operação financeira com segurança regulatória.

7. Automação de relatórios regulatórios e conformidade

O Banco Central aumenta as exigências para provedores de serviços de TI conectados à RSFN em temas como segurança da informação, auditorias e continuidade de negócios. Normas recentes reforçam esse movimento. Em paralelo, estruturas operacionais obrigatórias para licença própria incluem diretoria de compliance regulatório, auditoria interna, controles de prevenção à lavagem de dinheiro e relatórios periódicos ao Banco Central.

Os relatórios obrigatórios abrangem CCS, CADOC, COSIF, DIMP e BacenJud para o Banco Central, além de obrigações tributárias para a Receita Federal e SUSEP. A automação desses relatórios reduz erros manuais e aumenta a previsibilidade no cumprimento de prazos.

Passos de implementação:

1. Mapear todas as obrigações regulatórias aplicáveis, como CCS, CADOC, COSIF, DIMP, BacenJud, SCR e DES-IF.

2. Implementar geração automática de arquivos regulatórios a partir do event log imutável.

3. Configurar conexão direta com a RSFN e o SPB para envio automatizado.

4. Adotar compliance-as-code para codificar requisitos regulatórios em templates de infraestrutura.

5. Monitorar prazos de entrega com alertas antecipados de 48 horas.

6. Manter trilha de auditoria completa de todas as transmissões regulatórias.

7. Testar geração de relatórios em ambiente de homologação antes de cada atualização normativa.

Checklist de automação regulatória:

• Mapeamento completo de obrigações regulatórias documentado

• Geração automática de CCS, CADOC, COSIF, DIMP e BacenJud

• Conexão direta com RSFN e SPB configurada

• Compliance-as-code implementado

• Alertas de prazo com 48 horas de antecedência

• Trilha de auditoria de transmissões regulatórias ativa

• Testes de relatórios em homologação antes de atualizações normativas

Migração de Banking as a Service para Core Banking

A Celcoin processa mais de R$ 30 bilhões em transações por mês e atende mais de 6 mil clientes, incluindo fintechs, bancos digitais, ERPs e varejistas. A plataforma permite que empresas iniciem operando sob as licenças da Celcoin no modelo Banking as a Service e migrem para Core Banking com licença própria sem trocar de infraestrutura tecnológica. O prazo de migração varia de uma semana a três meses, conforme a complexidade da estrutura existente.

Conforme mencionado anteriormente, a infraestrutura da Celcoin suporta a oferta de produtos de crédito por empresas aos seus clientes finais.

A tabela a seguir resume as principais funcionalidades da plataforma Celcoin e como cada uma se converte em benefícios práticos para sua operação:

Funcionalidade da Celcoin	Benefício para sua empresa
APIs modulares	Integrações mais rápidas, com redução de custos e prazos de desenvolvimento.
Experiência e suporte ao desenvolvedor	Documentação, SDKs e sandboxes reduzem ciclos de integração e custos de engenharia.
Capacidade de lançamento rápido	Módulos pré-construídos e entrega via SaaS aceleram lançamentos, melhorando o tempo para geração de receita e a competitividade.
Distribuição white-label e embutida	Suporte a produtos financeiros com marca própria.
Escalabilidade com confiabilidade	Solução com alta disponibilidade e escalável na nuvem mantém serviços funcionando em altos volumes, protegendo sua receita.
Cobertura de diversas possibilidades de pagamentos, incluindo crédito	Oferta de pagamentos e emissão de crédito aumenta conversão, ARPU e fidelização.
Acesso a dados e personalização	Dados e análises via Open Finance permitem ofertas personalizadas, com impacto direto em conversão e retenção.
Compliance e conformidade como princípio	KYC, AML e relatórios integrados reduzem risco regulatório e aceleram ciclos de vendas.
Prevenção de fraude e controles de risco	Monitoramento baseado em IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.
Força do ecossistema de parceiros da Celcoin	Parcerias e integrações com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado.

A Resolução Conjunta nº 16/2025 do Banco Central e do CMN criou o primeiro arcabouço regulatório específico para Banking as a Service no Brasil, com prazo de adequação até 31 de dezembro de 2026. Planejar a migração com antecedência reduz retrabalho técnico e custos evitáveis, principalmente quando o produto financeiro se torna central ao negócio.

Perguntas frequentes

Quanto tempo leva a migração de Banking as a Service para Core Banking na Celcoin?

O prazo varia de uma semana a três meses. O fator determinante é a complexidade da estrutura existente. Empresas com arquiteturas mais simples e dados bem organizados costumam concluir a migração em poucos dias. Operações com múltiplos sistemas legados, grande volume de dados históricos e integrações complexas podem levar até três meses. A Celcoin disponibiliza uma equipe dedicada de suporte técnico para conduzir o processo em todas as etapas.

Quais relatórios regulatórios são automatizados pela Celcoin?

A Celcoin automatiza os principais relatórios exigidos pelo Banco Central, pela Receita Federal e pela SUSEP, incluindo CCS, CADOCs, COSIF, DIMP, BacenJud, SCR e DES-IF. A geração e o envio dos arquivos ocorrem diretamente por conexão com a RSFN e o SPB, o que elimina processos manuais e reduz o risco de erros ou atrasos no cumprimento de prazos regulatórios.

Como realizar testes de carga em uma plataforma de banco digital sem impactar a produção?

A abordagem recomendada combina ambientes de staging com dados anonimizados e ferramentas como k6, Gatling ou Apache JMeter para simular cargas progressivas. Os testes devem cobrir cenários de 2 a 100 usuários simultâneos para identificar o ponto de ruptura. Soak tests de 24 horas ajudam a detectar degradação gradual. Chaos engineering pode ser executado em produção com governança rigorosa, incluindo aprovações, rastreabilidade e rollback automático, como já praticam grandes bancos digitais brasileiros.

O que muda na arquitetura ao migrar de Banking as a Service para Core Banking com licença própria?

A principal mudança é a integração direta da licença regulatória própria à infraestrutura tecnológica, com assunção da responsabilidade pelos relatórios ao Banco Central, pela gestão do Ledger e pela conexão direta com o SPB. Do ponto de vista arquitetural, a empresa passa a controlar o Core Banking completo, incluindo gestão de contas, tesouraria e Open Finance, sem depender de licenças de terceiros. Na Celcoin, essa transição preserva a continuidade operacional e a escalabilidade já conquistada.