ARQUITETURA

NUBANK
GRUPO 1

Arthur Almeida
Cristina Silva
Moises Souza
Rodrigo Filomeno
Wagner Martins

2
 AGENDA
INFRAESTRUTURA
Tecnologias escolhidas e suas
motivações.
Implementação de
infraestrutura automatizada,
imutavel, e composta por
multiplos shardings.
COMUNICAÇÃO
Arquitetura de camadas e suas
motivações.
Estilo de escrita de
componentes derivados de
Arquitetura Hexagonal.
SERVIÇOS
Serviços de dominios distintos
interagindo por HTTP e
mensageria, orientados a
eventos.
Construção de funcionalidades
cross-serviços.
3
UM
POUCO DA
HISTÓRIA

4
US$ 25
Valor de mercado
bilhões

26.000.000
Usuários na conta digital

+Microserviços
150 em Clojure
5
O que escolher?
ARQUITETURA

6
MONOLÍTICO // MICROSERVIÇOS
Desenvolver um serviço o mais rápido
possível e, para testar o mercado, e
refatorar depois de validar a ideia.
//
Investir tempo em infraestrutura
automatizada e melhores práticas, para
ganhar velocidade em mudanças futuras ao
ganhar escala.

7
PRINCIPAIS BENEFÍCIOS
Escalabilidade Resiliencia Facilidade de Deploy
Nubank sempre teve,
A medida que é possível Se um componente de um
desde sua fundação em
modificar ou adicionar sistema falhar, mas essa
2013, uma adesão forte à
novos recursos ao sistema falha não ocorrer em
cultura de DevOps.
sem precisar mexer no cascata, você pode isolar
núcleo dele, evitando que o problema e o resto do O Continuous Deployment
ocorram problemas e sistema pode continuar já foi feito com scripts
conflitos. trabalhando. bash e com o tempo
ganhou maturidade.
Hoje é utilizado GoCD para
essas automatizações.

8
9
10
11
PRINCIPAIS BENEFÍCIOS
Heterogeneidade Composibilidade Substituibilidade
Nubank tem uma stack Nubank lançou desde sua Nubank integra com
técnologica quase que criação em 2013, diversos third-party e vendors
100% em Clojure + serviços bancários, os externos. A integração é
Datomic + Kafka. serviços pré-existentes feita através de um
interagem com novos para microserviço.
Abriram mão da
construir esses produtos.
heterogeneidade em prol Ao desejar fazer a troca de
de maturidade de Monólitos se mostram fornecedor ou entidade
desenvolvimento e flexíveis a evolução, à integradora, basta trocar
monitoramento já medida que o microserviço de fazendo
alcançado em Clojure. funcionalidades são essa comunicação.
criadas cross-serviços.

12
1 INFRAESTRUTURA
AWS, Docker, Datomic, Kafka, Go CD,
Infraestrutura Imutável, Shardings
PRINCIPAIS TECNOLOGIAS

Estrutura de nuvem Plataforma de Servidor de integração

utilizada para fazer virtualização para contínua. Utilizado na
automação da entregar software em automação dos
infraestrutura. pacotes, facilitando e deploys.
agilizando o deploy.

14
 PRINCIPAIS TECNOLOGIAS

Banco de dados que guarda as Sistema de mensageria utilizado na

mudanças de estado dos dados, comunicação assíncrona dos
assim não há perigo de perda de serviços, tem como principal
dados por conta das transações. característica a persistência de
mensagens.

15
INFRAESTRUTURA IMUTÁVEL
DOCKER, IMAGENS E CONTAINERS CONTINUOUS DEPLOYMENT E BLUE GREEN

Uma nova versão de serviço é a soma da imagem
docker com a nova versão do software. Os
containers são levantados em multi-account usando
AWS ECS.
A substituição do componente como um todo ocorre
para evitar que o estado de um servidor cause
comportamentos inesperados nos serviços.
Ao implementar uma nova versão do serviço, as
instâncias em produção são duplicadas. Instâncias
com as novas versões são criadas e apenas depois
de serem tidas como saudáveis, as instâncias com
versões anteriores são destruídas.
Não ocorre a substituição do software em um
servidor já configurado, pois a versão do SO e dos
pacotes instalados poderia influenciar no resultado.

Existe uma preocupação muito grande por parte da equipe de engenheiros do Nubank, com o estado imutável de
sua arquitetura. Tal preocupação permeia as decisões por base de dados, linguagem de programação, estratégia
de deploy e escalonamento de serviços.

16
SHARDING

Envios

Recebimentos
Saldos

Integração
Banco Central
500 mil
usuários
{
Pagamento Cartões de
de Faturas Crédito

17
2 COMUNICAÇÃO
Tolerant Readers, Ports, Adapters,
Side Effects and Pure Functions
ARQUITETURA HEXAGONAL

PORTAS HTTP, Kafka, E-mail, Datomic, File Storage, Metrics

ADAPTADORES Schema externo para Schema interno

CONTROLADORES Compositores de resultados com efeitos colaterais

LÓGICA DE NEGÓCIO Executores de lógica de negócio puras

19
BIBLIOTECAS COMPARTILHADAS

Datomic

Kafka Services can and should

make heavy use of
third-party libraries to reuse
Core Logic
common code. But they don't
get us all the way there.
HTTP

Sam Newman

20
TOLERANT READERS
PRODUTORES CONSUMIDORES

Validação dura de schema enviado para o barramento Consumo flexível do schema, com as informações
de mensageria e flexibilidade para evoluir esse mínimas requeridas para execução do serviço. Os
modelo para atender outros sistemas e casos de uso. demais campos são ignorados.

O schema do payload publicado pode ser uma Confia em sua fonte de dados e não realiza
representação do que é utilizado internamente no validações no payload consumido. Ao receber,
serviço, mas não existe uma obrigatoriedade quanto converte o necessário schema para o modelo de
a isso. dados interno.

Originalmente existia um repositório central com todos os schemas produzidos por um serviço, ao lançar uma
nova versão ocorria um bump de versão, em consumidores e produtores que tornava o processo sujeito a falhas,
denunciadas pelas baterias de testes.

21
“Be conservative in what you do,
be liberal in what you accept
from others.” – Jon Postel

22
COMUNICAÇÃO ASSÍNCRONA

Datomic Datomic
response
Kafka Kafka

Core Logic Core Logic

request

HTTP HTTP

23
3 SERVIÇOS
Microservices, Event Sourcing,
Back-for-Front
DESENVOLVIMENTO
fatura

Faturas
Componentes de software criados
Equipe de Faturas
em arquitetura hexagonal, com
banco de dados isolados e
autoridade sobre o domínio de saldo
negócio que tratam.
Saldos
Alinhamento organizacional, cada Equipe de Saldos
squad é responsável pela criação e
evolução de um conjunto de
microsserviços. antecipação

Antecipações
Equipe de Antecipações

25
 fatura Load
OPERAÇÃO Balance

As requisições HTTP do cliente

chegam em um load balancer, que
fica na frente das várias instâncias saldo
de um mesmo serviço. Load
Balance
O load balancer distribui o tráfego
para uma instância selecionada a
partir de uma política de
balanceamento.

Load
Balance
antecipação

26
EVENT SOURCING
Envios
OPERAÇÃO

Cada operação realizada por um serviço é avisada a

outros serviços por meio de um objeto evento que é
salvo e mantém um histórico de todas as mudanças
de estado das transações.

BENEFÍCIOS

Toda mudança de estado é armazenada.

Facilidade em consultar estados anteriores.

Saldos

27
BACK-FOR-FRONT (BFF) E GRAPHQL
Serviço para servir o front-end,
se comunica com a rede interna Envios
de microsserviços, é
responsável por agregar e
preparar informações para
serem enviados ao cliente.
BFF Recebimentos
Utiliza hypermedias, de forma
que o front-end apenas tenha
que conhecer poucos endpoint
para executar suas
funcionalidades. Saldos

28
CRÉDITOS
Um agradecimento especial para todas as pessoas
que criaram e disponibilizaram estes recursos
gratuitamente:
╸ Template da apresentação por SlidesCarnival
╸ Fotografias por Unsplash
╸ Ilustrações por Pixsellz

29