A arquitetura por trás de um banking que escala sem tocar no core
Como O Amplify escala banking com arquitetura event-driven, isolamento de falhas e auto-scaling, sem reescrever o core. As decisões técnicas por trás da plataforma.
Equipe Sciensa
TL;DR: um banco médio que precisa lançar um produto novo ou aguentar um pico de transações costuma encarar a mesma escolha desconfortável: reescrever o core, com o custo e o risco que isso carrega, ou empurrar o problema com gambiarra. O Amplify parte de um terceiro caminho, uma camada enterprise que se conecta ao core atual e resolve o que ele não resolve sozinho: escala horizontal, isolamento de falhas e velocidade de lançamento. Este artigo descreve as três decisões técnicas que sustentam isso, a arquitetura event-driven, o isolamento por design e o auto-scaling cloud-native, e o que um caso real mostrou em produção.
Em um feriado prolongado, o volume de PIX de um dos clientes dobrou em pouco mais de duas horas. Nenhum pré-aviso comercial, nenhuma janela de planejamento, só o gráfico de transações subindo enquanto a operação assistia. A infraestrutura absorveu o pico adicionando capacidade sozinha e voltou ao normal depois, sem ninguém abrir um chamado no meio da madrugada. Esse é o tipo de evento que separa uma arquitetura que escala de uma que promete escalar, e é ele que este artigo destrincha.
Um CTO de middle banking ou fintech que avalia uma camada por cima do core costuma fazer a mesma pergunta de três formas: o que acontece quando o volume triplica, o que acontece quando um serviço cai, e o que precisa ser reescrito daqui a dois anos. As três respostas estão no desenho da arquitetura, então é por ele que começamos.
Neste artigo
- Por que orientada a eventos
- Isolamento de falhas por design
- Cloud-native, para escalar sem virada de chave
- O teste real: o pico de transações
- O que um caso real mostrou em produção
- Perguntas frequentes
- O que isso muda na decisão
Por que orientada a eventos
A decisão mais estrutural do Amplify foi tratar cada transação, cadastro, aprovação e pagamento como um evento publicado em tempo real, em vez de uma chamada síncrona em que um serviço espera a resposta de outro antes de seguir. Isso parece detalhe de implementação até você comparar os dois modelos lado a lado.
| Dimensão | Monolito tradicional | O Amplify event-driven |
|---|---|---|
| Latência | 1 a 3 segundos | menos de 100ms |
| Escalabilidade | Vertical, troca de servidor | Horizontal, adiciona instâncias |
| Deploy | Tudo junto, tudo para | Serviços independentes |
| Falhas | Efeito cascata | Isoladas por serviço |
A queda de segundos para menos de 100ms não vem de otimizar o código dentro do monolito, porque isso deixaria a espera intacta. Ela vem de eliminar as chamadas bloqueantes, aquelas em que um serviço fica parado aguardando outro. O barramento de eventos, que na plataforma roda sobre Apache Kafka, desacopla quem produz o evento de quem consome, e com isso um serviço de antifraude mais lento segue seu próprio ritmo sem prender a fila do PIX. Os valores de latência acima são divulgados pela própria plataforma e valem como ponto de partida para a due diligence técnica, ainda sem status de SLA contratual confirmado.
Isolamento de falhas por design
A pergunta que todo arquiteto de banco faz é sobre o modo de falha: o que quebra primeiro e o que acontece com o resto do sistema logo depois. Em um monolito, uma exceção não tratada em um módulo de relatórios pode subir até derrubar o processamento de PIX, porque os dois compartilham processo, memória e ciclo de deploy. É esse risco que o Amplify corta ao separar cada domínio, contas, ledger, PIX, cartões e antifraude, em serviços com estado próprio que só conversam por mensagem assíncrona.
O desenho segue os princípios do modelo de atores: unidades de processamento com estado encapsulado, sem memória compartilhada, que trocam mensagens em vez de chamar função umas das outras diretamente. Quando uma unidade falha, o supervisor reinicia apenas ela e o restante do sistema continua rodando sem perceber. É esse isolamento que sustenta a promessa de falha contida e recuperação automática sem intervenção manual. Se a implementação usa literalmente um runtime de atores ou outro mecanismo equivalente é uma checagem que vale fazer com o time de engenharia antes de usar a analogia em um parecer técnico formal.
Cloud-native, para escalar sem virada de chave
Cloud-native, no Amplify, significa duas coisas concretas. A primeira é infraestrutura que se ajusta ao tráfego sem alguém abrir um chamado pedindo mais servidor, com provisionamento automático conforme a demanda, redundância em múltiplas zonas e recuperação em poucos minutos. A segunda é uma arquitetura em camadas independentes, o que permite a um cliente ativar PIX e antifraude sem herdar o peso de módulos que não usa.
São quatro camadas, e cada uma pode ser substituída ou desligada sem quebrar as demais.
Essa separação é o argumento técnico real contra reescrever o core inteiro só para adicionar um produto novo. É também o que sustenta a promessa de escala que a plataforma publica: crescer de mil para um milhão de contas sem refatorar a arquitetura, com uptime garantido e recuperação de desastres automática. São capacidades divulgadas pela própria plataforma, sem medição própria feita para este artigo, e servem de base para a avaliação técnica de quem for contratar.
O teste real: o pico de transações
O cenário do feriado com que este artigo abriu é o exemplo didático desse teste, porque o volume de PIX pode dobrar em poucas horas de forma concentrada, sem o tempo de reação que um crescimento gradual permite. O mecanismo que responde a esse pico é o mesmo que o Amplify descreve para a Black Friday e para o fechamento de folha: escalabilidade horizontal automática, em que a plataforma adiciona instâncias conforme a demanda sobe e as reduz depois que o pico passa, sem intervenção manual e sem a degradação típica de um sistema dimensionado só para o volume médio do dia. O throughput sustentado nesse tipo de evento é um número que ainda falta documentar publicamente, então o exemplo do PIX vale como cenário ilustrativo, e não como benchmark medido.
O que um caso real mostrou em produção
Fora do slide, o teste mais honesto de qualquer arquitetura é um projeto com prazo real. O caso mais concreto que temos é o de uma das maiores plataformas de delivery do país, que precisava de banking PJ completo para os seus parceiros, com PIX, boletos, DDA e um caixa digital próprio. O projeto foi do kickoff ao go-live em quatro meses e chegou a 8 mil contas no rollout inicial, com 100% de compliance BACEN PIX.
O Head de Engenharia do cliente descreveu a entrega assim: "Precisávamos de um parceiro assertivo para acelerar nosso produto bancário dentro de prazos extremamente apertados. A Sciensa entrou e acelerou o desenvolvimento de forma significativa, com precisão, disciplina de dados e segurança em cada etapa." Os números que a plataforma divulga para esse tipo de projeto, 10 vezes mais rápido que um build interno, 90% menos bugs que um desenvolvimento do zero e 9 vezes o retorno do investimento nos primeiros 12 meses, são comparações que ela faz contra o cenário de construir a mesma coisa internamente, com a metodologia de medição a confirmar antes de citar para um board.
Perguntas frequentes
O Amplify substitui o core banking?
Não. O Amplify se conecta ao core atual como uma camada enterprise por cima dele e acrescenta escala, isolamento de falhas e novos produtos sem exigir a reescrita do núcleo. O cliente ativa só os módulos de que precisa, como PIX ou antifraude, sem tocar no que já funciona hoje.
Como a arquitetura event-driven reduz a latência?
Ela elimina as chamadas síncronas, aquelas em que um serviço fica parado esperando a resposta de outro. Cada transação vira um evento publicado em tempo real sobre um barramento, e os serviços consomem no próprio ritmo. A plataforma reporta latência abaixo de 100ms, um valor que vale confirmar sob carga de pico.
O que acontece se um serviço do banco cair?
Cada domínio, como PIX, cartões ou antifraude, roda isolado, com estado próprio e comunicação só por mensagem. Quando um serviço falha, o supervisor reinicia apenas ele e o restante continua operando. Uma falha em relatórios não derruba o processamento de pagamentos, porque os dois não compartilham processo nem memória.
O Amplify aguenta um pico de PIX em feriado?
O desenho prevê escalabilidade horizontal automática: a plataforma adiciona instâncias conforme a demanda sobe e as reduz quando o pico passa, sem intervenção manual. É o mesmo mecanismo usado para a Black Friday e para o fechamento de folha. O throughput exato em pico ainda é um número a confirmar com engenharia.
Quanto tempo leva para lançar um produto bancário novo?
Depende do escopo. O caso público mais concreto foi um banking PJ completo levado do kickoff ao go-live em quatro meses, com PIX, boletos, DDA e caixa digital próprio. A arquitetura modular permite ativar produtos sem reescrever o core, o que encurta o tempo entre a decisão e o lançamento.
O que isso muda na decisão
Para quem avalia essa camada, a pergunta técnica correta vai além de saber se o Amplify é rápido. Ela pede três respostas concretas: se a arquitetura isola o risco de um domínio como o PIX do risco de outro como relatórios, se o sistema escala horizontalmente sem depender de um evento manual de infraestrutura, e se compliance como LGPD, BACEN e PCI DSS está embutido no desenho de cada módulo, não remendado depois. Nos três pontos, a resposta documentada é sim, com as ressalvas de medição que este artigo deixou explícitas.
O próximo passo de um arquiteto sério pede mais do que acreditar em um artigo: pede ver a arquitetura rodando com o próprio volume de transações. Fale com um especialista da Sciensa e agende uma demonstração técnica do Amplify com o cenário de carga da sua operação.
