Transferir como PDF, PPTX
![(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](https://image.slidesharecdn.com/arquiteturamodernafintechnubank-181017134959/75/Arquitetando-uma-instituicao-financeira-moderna-Lucas-Cavalcanti-25-2048.jpg)
![(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](https://image.slidesharecdn.com/arquiteturamodernafintechnubank-181017134959/75/Arquitetando-uma-instituicao-financeira-moderna-Lucas-Cavalcanti-27-2048.jpg)
![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](https://image.slidesharecdn.com/arquiteturamodernafintechnubank-181017134959/75/Arquitetando-uma-instituicao-financeira-moderna-Lucas-Cavalcanti-41-2048.jpg)
Carregado poriMasters
Arquitetando uma instituição financeira moderna - Lucas Cavalcanti
O documento descreve a arquitetura e infraestrutura de uma instituição financeira moderna, com foco na utilização de tecnologia como Clojure, Datomic e Kafka para gerenciar serviços financeiros de forma escalável e resiliente. Ele aborda a imutabilidade na stack tecnológica, o aumento rápido de clientes e a implementação de microservices, além de discutir desafios relacionados à escalabilidade e à gestão de dados. O texto também menciona práticas de programação funcional e o uso de ETL para análise de dados em tempo real.
Mais conteúdo relacionado
![[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기](https://cdn.slidesharecdn.com/ss_thumbnails/ndc18-180429152609-thumbnail.jpg?width=640&height=640&fit=bounds)
![[NDC2017] 딥러닝으로 게임 콘텐츠 제작하기 - VAE를 이용한 콘텐츠 생성 기법 연구 사례](https://cdn.slidesharecdn.com/ss_thumbnails/v072-170426075401-thumbnail.jpg?width=640&height=640&fit=bounds)
Semelhante a Arquitetando uma instituição financeira moderna - Lucas Cavalcanti
Arquitetando uma instituição financeira moderna - Lucas Cavalcanti
- 1. Arquitetando uma instituiçãofinanceira moderna SOUTHEAST BRAZIL REGION FROM SPACE
- 2. CARTÃO DE CRÉDITO Setembrode 2014
- 3. 1,3 2,5 3,8 5,0 Set-14 Fev-15 Jul-15Dez-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 NOSSASTACK 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 NOSSASTACK 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 NOSSASTACK 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 NOSSASTACK 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 NATURALPOSITIVA < 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ÃODE 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.
- 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 AuthorizerBilling 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ÇÃODE COMPRAS CLIENTE
- 15.
- 16. MASTERCARD INTERFACE DEVICE AUTHORIZER AUTORIZAÇÃONO EMISSOR 1 Estabelece uma conexão 2 Recebe pedidos de autorização
- 17. MASTERCARD INTERFACE DEVICE AUTHORIZER AUTORIZAÇÃONO EMISSOR: ISO-8583 ISO-8583 Binary Message HARDWARE SECURITY MODULE
- 18. MASTERCARD INTERFACE DEVICE AUTHORIZER AUTORIZAÇÃONO EMISSOR: REQUISITOS ISO-8583 Binary Message HARDWARE SECURITY MODULE (HSM) 1.Altamente disponível 2.Infraestrutura física
- 19. LAYOUT DOS SERVIÇOSDE 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 realworld” (AWS VPC) 100+ microservices KAFKA COMO A LIGAÇÃO ENTRE OS AMBIENTES
- 21. CONTABILIDADE DE PARTIDASDOBRADAS 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çõesJuros 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: OMODELO 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: ROTEIROSCONTÁ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 AFALHAS, 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 dividira 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 bancoeram 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 pramudar 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: UNIDADESDE 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: UNIDADESDE 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ÍDIAPARA 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 AOESCALAR 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ÂNCIAA FALHAS Padrões simples para isolamento das falhas e sua recuperação CLIENT HTTP SERVER SERVER SERVER SERVER FINAGLE
- 38. PADRÕES DE TOLERÂNCIAA 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 + OAMBIENTE 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 01NOV 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: MARGEMDE CONTRIBUIÇÃO do double entry do ERP estamos lucrando?
- 44. TRANSFERÊNCIAS EM TEMPOREAL 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 TEMPOREAL 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) Centenasde 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 MODELODE 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.
- 50.