Lucas Cavalcanti - Principal Engineer, Nubank Sistemas de software costumam ficar cada vez mais difíceis de evoluir e manter na medida que o tempo passa e mais funcionalidades são adicionadas. No Nubank, após 4 anos de evolução, adicionar novas funcionalidades é tão ou mais fácil do que era há 3 anos atrás. Nessa palestra vamos explorar as principais características que possibilitaram essa evolução rápida e contínua de funcionalidades, como exemplo: microsserviços com o escopo bem definido, integração assíncrona entre serviços usando Kafka, verificação de schemas nas integrações, Clojure e programação funcional. Apresentado no InterCon 2018

1. Arquitetando uma instituição financeira moderna
SOUTHEAST BRAZIL REGION FROM SPACE

2. CARTÃO DE CRÉDITO
Setembro de 2014

3. 1,3
2,5
3,8
5,0
Set-14 Fev-15 Jul-15 Dez-15 Mai-16 Out-16 Mar-17 Ago-17 Jan-18 Jun-18
CRESCENDO RAPIDAMENTE NUM DOMÍNIO COMPLEXO
# de clientes (M)
Cartão de Crédito
Clientes Cartão
5M
Países
200
Pedidos únicos
20M
Compras
700M
Deploys por dia
10s
Microservices
200
Engineers
180
Clientes NuConta
2.5M

4. IMUTABILIDADE NA NOSSA STACK
LISP rodando na JVM
Funcional (opinionated), immutable
data structures
Simples, concisa, rápida,
concorrente
Ciclos rápidos de feedback no REPL
Tipagem opcional (schemas)
CLOJURE
DATOMIC
CLOUD
KAFKA

5. IMUTABILIDADE NA NOSSA STACK
para os dados
CLOJURE
DATOMIC
CLOUD
KAFKA
Sempre acumula
Transações ACID reificadas,
preserva o que mudou e quando
Queries usando estruturas de
dados (Datalog)
Cloud nativo com cache integrado
e leitura escalável

6. IMUTABILIDADE NA NOSSA STACK
Log particionado, persistente e
imutável
Desacoplamento lógico entre serviços
Desacoplamento temporal, útil para
cargas de trabalho assimétricas
Isolamento entre falhas e recuperação
(circuit breakers, dead letters)
Processamento financeiro em batches
expressado como um stream de
mensagens
CLOJURE
DATOMIC
CLOUD
KAFKA

7. IMUTABILIDADE NA NOSSA STACK
Infra as code (AWS)
Imutável após o provisionamento
(Docker)
Blue-Green deploys a nível de
serviço e de empresa
Kubernetes para velocidade de
deploy e escalabilidade
CLOJURE
DATOMIC
CLOUD
KAFKA

8. BENEFÍCIOS FUNCIONAIS
CONTRATAÇÃO
SELEÇÃO NATURAL POSITIVA
< 1 MÊS JÁ PRODUTIVOS
SIMPLICIDADE
FUNÇÕES PURAS PEQUENAS
FÁCIL DE DESACOPLAR
CONSISTÊNCIA
COMPOSIÇÃO DE UM NÚMERO
PEQUENO DE FUNCIONALIDADES
IDIOMÁTICAS DA LINGUAGEM
Nubank HQ
São Paulo, Brazil

9. Diplomat architecture (Ports & adapters enhanced by Nubank)
Lógica de negócio em funções puras (verde)
Controller com lógica que liga o fluxo entre as portas (amarelo)
Uma Port é uma das entradas da aplicação (azul)
Um adapter é a ponte entre a port e o controller (vermelho)

10. ARQUITETURA DO CARTÃO DE CRÉDITO
Greenfield MVP
Anti-fraud
Collections
General
Ledger
Phone + Chat
Authorizer
Securitization ETL
Credit
Scoring
Customer
Acquisition
(KYC)
Credit Limits
Logistics
Card
Origination
Billing
Installment
Purchases
FX
Backoffice
(CRM)
Notification
Chargeback
Bill Pay
Infosec
Rewards +
Merchants
Marketing

11. NUCONTA
Outubro de 2017
13

12. ARQUITETURA NÚCLEO BANCÁRIO + CARTÃO DE CRÉDITO
INFRAESTRUTURA
Rewards +
Merchants
Marketing
Investment
Management
Treasury +
Risk
Realtime
Transfers
Lending +
Interest
Rates
Tax
Anti-fraud
Collections
General
Ledger
Phone + Chat
Authorizer
Securitization ETL
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Card
Origination
Billing
Installment
Purchases
Credit Limits
FX
Backoffice
(CRM)
Notification
Chargeback
Bill Pay
Infosec

13. AUTORIZAÇÃO DE COMPRAS
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Anti-fraud
Card
Origination
Authorizer Billing
Installment
Purchases
Credit Limits
Investment
Management
FX
Collections
Treasury +
Risk
Rewards +
Merchants
Realtime
Transfers
Backoffice
(CRM)
Lending +
Interest
Rates
Notification
General
Ledger
Securitization
Marketing
Chargeback
Tax
Bill Pay
Phone + Chat
Infosec
ETL
INFRAESTRUTURA

14. LOJA
ADQUIRENTE
BANDEIRA
EMISSOR
CADEIA DE AUTORIZAÇÃO DE COMPRAS
CLIENTE

15. BANDEIRA
EMISSOR
AUTORIZAÇÃO NO EMISSOR

16. MASTERCARD INTERFACE DEVICE
AUTHORIZER
AUTORIZAÇÃO NO EMISSOR
1 Estabelece uma conexão
2 Recebe pedidos de autorização

17. MASTERCARD INTERFACE DEVICE
AUTHORIZER
AUTORIZAÇÃO NO EMISSOR: ISO-8583
ISO-8583 Binary Message
HARDWARE SECURITY MODULE

18. MASTERCARD INTERFACE DEVICE
AUTHORIZER
AUTORIZAÇÃO NO EMISSOR: REQUISITOS
ISO-8583 Binary Message
HARDWARE SECURITY MODULE (HSM)
1.Altamente disponível
2.Infraestrutura física

19. LAYOUT DOS SERVIÇOS DE AUTORIZAÇÃO
fraud fraud
HSMHSM
crypto crypto
• Poucos serviços altamente
disponíveis
• No mesmo local da
máquina da MasterCard
• Isolada: fluxo de
autorização não precisa de
comunicação com a nuvem
• Ativo-ativo para
recuperação de desastres
Thrift
Finagle Server
authorizer authorizer authorizer authorizer
Finagle Client
router
ISO 8583
router
Proprietary
protocol

20. “neverland”
(nubank datacenter)
kafka
“the real world”
(AWS VPC)
100+ microservices
KAFKA COMO A LIGAÇÃO ENTRE OS AMBIENTES

21. CONTABILIDADE DE PARTIDAS DOBRADAS
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Anti-fraud
Card
Origination
Authorizer Billing
Installment
Purchases
Credit Limits
Investment
Management
FX
Collections
Treasury +
Risk
Rewards +
Merchants
Realtime
Transfers
Backoffice
(CRM)
Lending +
Interest
Rates
Notification
General
Ledger
Securitization
Marketing
Chargeback
Tax
Bill Pay
Phone + Chat
Infosec
ETL
INFRAESTRUTURA

22. Compras Pagamentos Contestações Juros Faturas
Devemos…
autorizar a compra?
bloquear o cartão?
cobrar juros?
LÓGICA DE NEGÓCIO DEPENDE DE DADOS DE VÁRIOS SERVIÇOS
Double Entry

23. DOUBLE ENTRY: O MODELO
ENTRADA CONTA CRÉDITO
CONTA DÉBITO
$
= 𝚺SALDO $
O saldo de uma conta é a soma de
seus créditos e débitos
O balancete do cliente é uma
função cumulativa do histórico
completo do cliente

24. DOUBLE ENTRY: ROTEIROS CONTÁBEIS
ENTRADA CONTA CRÉDITO
CONTA DÉBITO
$
NOVA-COMPRA
NOVO-PAGAMENTO
…
ENTRADA 2 CONTA CRÉDITO
CONTA DÉBITO
$
ENTRADA 3 CONTA CRÉDITO
CONTA DÉBITO
$
MOVIMENTAÇÃO

25. (def unsettled-purchase
[{:entry/debit-account :book-account-type.asset/unsettled
:entry/credit-account :book-account-type.liability/unsettled-counterparty
:entry/amount #'transaction-amount
:entry/post-date #'produced-date}
{:entry/debit-account :book-account-type.liability/current-limit-counterparty
:entry/credit-account :book-account-type.asset/current-limit
:entry/amount #'transaction-amount
:entry/post-date #'produced-date}])
DOUBLE ENTRY: EXEMPLO DE MOVIMENTAÇÃO

26. ordem importa (i.e. movimentações não são comutativas)
eventos atrasados (ex. um pagamento feito há 3 dias)
Correção de invariantes
Vazão de escrita
DOUBLE ENTRY: DESAFIOS

27. (def loss-property
(prop/for-all [events (gen/vector (gen/one-of [gen-adjustment gen-payment gen-tx])
1 10)
initial-state (->> rbh/initial-state-gen
(gen/such-that (comp not #{:late :pre-loss} :state)))
loss-event (tg/make-generator {:event (s/enum :pre-loss
:credit-loss
:id-fraud-loss)
:post-date LocalDate
:produced-at LocalDateTime})]
(check-properties events initial-state loss-event)))
DOUBLE ENTRY: TESTES GENERATIVOS DE INVARIANTES

28. INFRAESTRUTURA TOLERANTE A FALHAS, COM SHARDS
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Anti-fraud
Card
Origination
Authorizer Billing
Installment
Purchases
Credit Limits
Investment
Management
FX
Collections
Treasury +
Risk
Rewards +
Merchants
Realtime
Transfers
Backoffice
(CRM)
Lending +
Interest
Rates
Notification
General
Ledger
Securitization
Marketing
Chargeback
Tax
Bill Pay
Phone + Chat
Infosec
ETL
INFRAESTRUTURA

29. GARGALOS DE ESCALABILIDADE
# de clientes (M)
Cartão de Crédito
1. limites de vazão do
banco de dados causam
throttling de escrita
2.latência de batches
impactam a experiência
do usuário
1,3
2,5
3,8
5,0
Set-14 Fev-15 Jul-15 Dez-15 Mai-16 Out-16 Mar-17 Ago-17 Jan-18 Jun-18

30. Necessidade de dividir a carga
Dados de clientes estão espalhados
entre vários serviços
Interações entre clientes são mínimas
É seguro particionar a base de
usuários
PLANEJANDO PARA ESCALAR

31. Escritas no banco eram o pior
dos gargalos
Opção: particionar
horizontalmente cada base de
dados
Mudar cada um dos serviços
para rotear escritas e leituras
pro shard apropriado
db shard s0 db shard s1 db shard s2
OPÇÃO #1: PARTITION SERVICE DATABASES
backend service

32. Esforço gigante pra mudar todos
os serviços
Não resolve os gargalos que não
são do banco de dados
Risco de poluir a lógica de
negócio com código de
infraestrutura
OPÇÃO #1: PROBLEMAS

33. OPÇÃO #2: UNIDADES DE ESCALA
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3
shard S0 shard S1 shard s2 . . .

34. OPÇÃO #2: UNIDADES DE ESCALA + ROTEAMENTO GLOBAL
shard S1 shard s2
SERVIÇO 4 SERVIÇO 5
global
SERVIÇO 6
compra depósito
shard S0
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3

35. OPTION #2: HIPERMÍDIA PARA INTERAÇÕES
shard S1
global
login
{"_links":
{"account": “https://s1-service2…”}}
{"_links":
{"account": “https://s1-service3…”}}
SERVIÇO 4 SERVIÇO 5 SERVIÇO 6
SERVIÇO 1 SERVIÇO 2
SERVIÇO 3

36. LIÇÕES APRENDIDAS AO ESCALAR
funcionam na prática, mas foi muito difícil mover
incrementalmente nessa direção
UNIDADES FUNCIONAM
sharding foi um projeto complexo
crescimento exponencial derrota intuição: use
modelos reais de crescimento para planejar
COMEÇAR CEDO
geram uma flexibilidade muito importante para o
roteamento dos shards
MENSAGERIA E HIPERMÍDIA
tornou o processo muito mais viável
INFRA IMUTÁVEL AUTOMATIZADA
lógica de negócio pode criar hot spots
reativação de leads antigos lotou o s0
CUIDADO COM HOTSPOTS
é estupidamente difícil (a gente conseguiu
praticamente evitar)
DIVISÃO DE DADOS EXISTENTES

37. PADRÕES DE TOLERÂNCIA A FALHAS
Padrões simples para isolamento das falhas e sua recuperação
CLIENT
HTTP
SERVER
SERVER
SERVER
SERVER
FINAGLE

38. PADRÕES DE TOLERÂNCIA A FALHAS
Padrões simples para isolamento das falhas e sua recuperação
PRODUCER
CONSUMER
1 Publica
2 Consome
TOPIC
DEADLETTER-TOPIC
MORTICIAN
4 Salva
5 Republica
DEADLETTERS CIRCUIT BREAKERS
SERVICE
1 Consome
3 Circuit breaker
ativa!
3 Exception!
Produz deadletter
2 Serviço
indisponível
4 Pausa o consumo
KAFKA

39. ETL + O AMBIENTE ANALÍTICO
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Anti-fraud
Card
Origination
Authorizer Billing
Installment
Purchases
Credit Limits
Investment
Management
FX
Collections
Treasury +
Risk
Rewards +
Merchants
Realtime
Transfers
Backoffice
(CRM)
Lending +
Interest
Rates
Notification
General
Ledger
Securitization
Marketing
Chargeback
Tax
Bill Pay
Phone + Chat
Infosec
ETL
INFRAESTRUTURA

40. 01 NOV 10:00
Robô 437aae3 aprova R$3 mil de limite01 NOV 11:00
Compra Mastercard, Starbucks, R$10009 NOV 08:00
Atendente aumenta o limite para R$5 mil15 NOV 15:00
Cliente bloqueia o cartão15 NOV 17:05
Cliente entra na lista de espera do cartão
DATOMIC PRIMER: EVENTOS ATRAVÉS DO TEMPO

41. 01 NOV 10:00
01 NOV 11:00
09 NOV 08:00
15 NOV 15:00
15 NOV 17:05
[<customer> :customer/id #uuid “b2c90…” 1]
[<account> :account/customer <customer> 2]
[<account> :account/limit 3000 2]
[<card> :card/account <account> 2]
[<card> :card/status :card.status/active 2]
[<purchase> :purchase/card <card> 3]
[<purchase> :purchase/amount 100 3]
[<purchase> :purchase/merchant “Starbucks” 3]
[<account> :account/limit 5000 4]
[<account> :account/limit 3000 4]
[<card> :card/status :card.status/blocked 5]
[<card> :card/status :card.status/active 5]
DATOMIC PRIMER: FATOS ATRAVÉS DO TEMPO
entidade atributo valor tx

42. “The DAG”
Funções puras (Scala SQL)
Recebe datasets, retorna
dataset
Metadados (schema,
partitions, path on S3,
performance)
Roda no Spark
DB1
Log S0
DB1
Log S1
DB2
Log S0
Dataset
Series
Kafka
topics
Datomic
DB logs
EXTRACTOR
Captura mudanças
Agrupamento
Conversão de formatos
Auto-correção
S3
contract 1
contract 2
dataset 1
dataset 2
policy
model
Logs do Datomic e do Kafka são extraídos para nosso data lake (S3) em
tempo real
Schemas analíticos (“contratos”) gerados a partir das entidades do Datomic
Shards recombina dos em uma única tabela lógica por entidade incremental
EXTRACT, TRANSFORM, LOAD

43. EXEMPLO ETL: MARGEM DE CONTRIBUIÇÃO
do double entry
do ERP
estamos lucrando?

44. TRANSFERÊNCIAS EM TEMPO REAL
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Anti-fraud
Card
Origination
Authorizer Billing
Installment
Purchases
Credit Limits
Investment
Management
FX
Collections
Treasury +
Risk
Rewards +
Merchants
Realtime
Transfers
Backoffice
(CRM)
Lending +
Interest
Rates
Notification
General
Ledger
Securitization
Marketing
Chargeback
Tax
Bill Pay
Phone + Chat
Infosec
ETL
INFRASTRUCTURE

46. TRANSFERÊNCIAS EM TEMPO REAL
1 Pedido de
transferência
In-shard
Transfers 3 Inicia transferência
Investments
2 Liquida investimento
Global
Transfers
4 Processa
transferência
(global)
Ledger
4 Débitos +
créditos SPB Client
EXTERNO
5 Kafka <> SOAP
5
INTERNO
Roteamento de
Shard
RSFN (XML)
SITRAF (TED)
Centenas de
bancos
6 Liquidação em
tempo real

47. RSFN (XML)
SITRAF (TED)
Centenas de
bancos
6 Liquidação em
tempo real
SISTEMA DE PAGAMENTOS BRASILEIRO
Modelo Hub and spoke para pagamentos nacionais
SPB Client
5 Kafka <> SOAP
Liquidação bruta, irrevogável e incondicional
de quantias ilimitadas
~R$1 trilhão transferidos por dia
06:30 - 18:30 dias úteis
Protocolo XML proprietário, mensageria IBM
MQ Series
Veja: https://www.bcb.gov.br/htms/novaPaginaSPB/VisaoGeralDoSPB.asp

48. RESUMO DO MODELO DE DOMÍNIO
Customer
Acquisition
(KYC)
Credit
Scoring
Logistics
Anti-fraud
Card
Origination
Authorizer Billing
Installment
Purchases
Credit Limits
Investment
Management
FX
Collections
Treasury +
Risk
Rewards +
Merchants
Realtime
Transfers
Backoffice
(CRM)
Lending +
Interest
Rates
Notification
General
Ledger
Securitization
Marketing
Chargeback
Tax
Bill Pay
Phone + Chat
Infosec
ETL
INFRASTRUCTURA

49. Estamos contratando
https://sou.nu/vagasnu
São Paulo, Brazil

50. Obrigado!
Lucas Cavalcanti
@lucascs
https://sou.nu/vagasnu