O blog da AWS
Como o Itaú Unibanco modernizou seu core bancário internacional com serviços Serverless da AWS
Por Ricardo Marques, Especialista Senior para AppMod & Serverless da AWS; Ivan da Cruz Rodolpho, Especialista de Engenharia do Itaú-Unibanco S.A., Eduardo Albero, Coordenador de Engenharia de TI do Itaú-Unibanco S.A.
O Itaú Unibanco é uma instituição financeira brasileira de grande porte, está entre os maiores bancos privados da América Latina, com presença em diversos países no mundo.
Utilizando serviços serverless da AWS, a instituição modernizou toda sua solução de contas correntes internacionais em um prazo de 15 meses, com custo 26 vezes menor comparando com outras soluções de mercado.
O desafio
Em meados de 2023, o Itaú iniciou um projeto que tinha a ambição de substituir toda sua solução de contas correntes internacionais. Durante seis meses, foram avaliadas alternativas disponíveis no mercado, com estudo detalhado das soluções oferecidas por cinco diferentes fornecedores de software.
Ao final destas análises o banco deparou-se com alto custo para adoção de uma solução de mercado. Baseando-se em experiências prévias do time com soluções serverless, onde já havia sido provada sua agilidade na construção, um baixo esforço de manutenção e baixo custo de utilização, optou-se pelo desenvolvimento in-house do novo core bancário, com serviços serverless como AWS Step Functions, AWS Lambda, Amazon DynamoDB, entre outros.
A solução
O novo sistema foi projetado em módulos independentes, separados de acordo com sua capacidade de negócio: Contas Correntes, Transferências, Tarifas, Juros e Contábil. Toda comunicação, seja ela entre os módulos ou com sistemas externos, é majoritariamente orientada a eventos, utilizando um broker Kafka como bus para integração entre domínios.
Fluxo automático de transferência internacional:
- O cliente acessa o internet banking para solicitar uma transferência internacional. É então publicado um evento de negócio contendo os detalhes da solicitação no broker Kafka.
- Uma função do AWS Lambda do módulo de Transferência consome as solicitações produzidas no broker Kafka e as encaminha para serem processadas em um workflow no AWS StepFunctions.
- O workflow faz as validações das regras de negócio, e solicita ao módulo de Contas Correntes, através do ApiGateway, que seja realizada uma movimentação na conta do cliente. Nesse momento é realizado o débito na conta corrente do cliente e registrado o movimento no extrato.
- Após receber a confirmação do processamento do movimento, o workflow envia uma mensagem para a fila no Amazon SQS, que centraliza a produção de eventos para o broker Kafka, solicitando que seja realizado o envio da transferência para a rede Swift. A integracão entre a fila no SQS e o Kafka é feita através de uma função do AWS Lambda.
- O sistema de mensageria internacional consome o evento contendo a solicitação, formata a mensagem e a envia para a rede Swift.
- Após a confirmação do processamento do pagamento pela rede Swift, o sistema de mensageria internacional produz um novo evento no Kafka contendo essa confirmação.
- O evento de confirmação é consumido pela função do AWS Lambda de Transferência e processado pelo workflow no AWS StepFunctions, que atualiza o status da solicitação.
- Após a atualização do status, é então produzido um novo evento informando o processamento da solicitação de transferência internacional no broker Kafka.
- O Internet Banking consome este evento para atualizar o status da solicitação, saldo e extrato da conta no canal. Uma função do AWS Lambda do módulo de Tarifas consome o mesmo evento e o envia para processamento em um outro workflow no AWS StepFunctions.
- Esse workflow, após as validações das regras de negócio, solicita ao módulo de Contas Correntes que seja realizado o débito na conta do cliente, assim como ocorreu com a transferência.
- O workflow de Tarifas, após receber a confirmação do processamento do débito, solicita a produção do evento no Kafka informando o processamento da tarifa.
- O Internet Banking consome o evento da tarifa para atualizar o saldo e extrato da conta.
Em todo este processo, duas métricas precisam ser destacadas:
- O processamento entre recebimento do evento de solicitação de pagamento (passo 2) até a geração do evento para a mensageria internacional (passo 5) ocorre em menos de 3s.
- O processamento entre o recebimento do evento de confirmação da mensageria (passo 7) até a geração do evento de conclusão do pagamento (passo 9) ocorre em menos de 1s.
Apesar de o processamento ser majoritariamente automático, em alguns casos se faz necessária a intervenção manual pela área de back office e, para isso, foi construído um portal.
Fluxo de intervenção manual no processo de transferência internacional:
- O site estático, publicado no Amazon S3 e disponibilizado através do Amazon CloudFront, é acessado pelos usuários do backoffice.
- Ao acessar o módulo de Transferências, o site faz uma requisição a uma API no Amazon API Gateway que encaminha a requisição para um BFF (backend for frontend) no AWS Step Functions, responsável pela orquestração da chamada.
- Caso o usuário queira listar as transferências do dia, a API no Amazon ApiGateway chama uma função no AWS Lambda que realiza a consulta em uma tabela do Amazon DynamoDB. Caso ele queira ver os detalhes de um pagamento específico, a API se integra diretamente à tabela.
- Caso o usuário queira editar ou criar uma transferência internacional, o workflow no AWS StepFunctions que contém as regras de negócio é chamado (o mesmo descrito no fluxo automático).
Todos os módulos do sistema possuem a mesma arquitetura: função Lambda para consumo de eventos do Kafka e para consulta dos dados no DynamoDB, workflow no AWS StepFunctions para o processamento dos eventos de negócio ou BFF para as telas, e tabelas no Amazon DynamoDB para armazenamento dos dados.
A solução toda consiste em:
- 25 workflows no AWS Step Functions, executando 12 mil fluxos de trabalho diários;
- 63 funções Lambda, processando 66 mil requisições diárias;
- 15 APIs no Amazon ApiGateway, processando 25 mil requisições diárias;
- 9 tabelas no Amazon DynamoDB, com 796 mil acessos diários.
Aceleradores do projeto
Além do conhecimento da equipe sobre as regras do produto e experiência com outras peças que tiveram integrações com a solução de core bancário, alguns fatores técnicos foram essenciais para acelerar o desenvolvimento do projeto:
- Lowcode do AWS StepFunctions: Após uma pequena curva de aprendizado foi possível entregar soluções de forma muito rápida, sem nenhum desenvolvimento de código. Tivemos algumas lições aprendidadas com o uso de Step Functions, como por exemplo, workflows muito grandes são complexos para dar manutenção. O ideal é quebrar em workflows menores quando posível.
- Reutilização de funções Lambda: As funções KafkaProducer (para geração de evento em tópico Kafka) e ApiProxy (para chamada de endpoints Rest privados através de workflows no StepFunctions) foram reutilizados por todos os módulos do sistema.
- Modelos de função Lambda: Foi criado um modelo para a função KafkaConsumer, utilizado por todos os módulos, contendo as configurações de infra, tratamento para recebimento de evento e tratamento de exceção. Com isso, o desenvolvimento de uma nova função não seria iniciada do zero, além de manter um padrão entre todas as funções.
- Esteira DevOps: O Itaú possui esteiras de implantação que são criadas e governadas por uma área específica, contendo guardrails que impedem que sejam utilizadas configurações indevidas. Isso faz com que as equipes foquem apenas no desenvolvimento do produto.
Conclusão
Devido a escolha de uma arquitetura serverless, e do conhecimento técnico e funcional da equipe, foi possível finalizar o projeto em apenas 15 meses, incluindo a migração de todas as contas correntes e seus dados históricos para o novo sistema, sem nenhum impacto aos clientes.
Comparando custos da solução desenvolvida com os valores orçados pelos fornecedores externos, o projeto trouxe uma grande economia para o banco: o custo de 1 ano de licenciamento e infraestrutura, considerando a proposta mais barata apresentada pelos fornecedores externos, equivale a 26 anos do custo da solução implementada usando serviços serverless da AWS.
A resiliência também era um fator importante em função da criticidade do negócio e do risco financeiro envolvido, uma vez que as contas internacionais são utilizadas principalmente por grandes empresas clientes. Toda a arquitetura precisava ter alta disponibilidade e, devido a natureza dos serviços serverless de serem regionais e distribuídos em 3 zonas de disponibilidade, o Banco Itaú pode implementar toda a solução com alta disponibilidade de forma simples.
A adoção dos serviços serverless da AWS nos permitiu implementar uma solução que uniu agilidade, otimização de custo e resiliência.
Para aprender mais sobre padrões e arquiteturas serverless, acesse Serverless Land.
Biografia dos autores
 |
Ricardo Marques é Senior AppMod & Serverless Specialist na AWS, com mais de 17 anos de experiência em desenvolvimento de software, arquiteturas de soluções escaláveis, cloud native, microsserviços, Serverless e segurança. Ele trabalha apoiando clientes de toda América Latina, ajudando-os em sua jornada para a nuvem. |
 |
Eduardo Albero é Coordenador de Engenharia de TI no Itaú Unibanco, com mais de 26 anos de experiência em desenvolvimento e sustentação de sistemas. Há 2 anos e meio ele lidera a equipe que tornou possível a entrega desse e de outros importantes projetos da comunidade de câmbio do banco. |
 |
Ivan da Cruz Rodolpho é Especialista de Engenharia de Software no Itaú Unibanco, com mais de 21 anos de experiência no desenvolvimento de software para o mercado financeiro. Atua há mais de 6 anos na comunidade de Câmbio do banco auxiliando as equipes no desenho e implementação de projetos utilizando os serviços AWS. |