Como escalar um fintech: O Ledger

Transcript

1. Como escalar uma fintech: Aprendizados da 3X Pay
2. Sobre mim: • Meu nome é Rafael Avelar Campos; • Engenheiro por formação; • Desenvolvedor há 6 anos; • Há 4 anos trabalhando com fintechs; • TypeScript para TUDO! • Vivendo na borda do caos das transações !
3. O que é uma fintech na prática?
4. Sobre a 3X Pay API PIX API PIX USDT Bets
5. 20 milhões+ de registros no ledger Alguns números: 30+ transações por segundo Cálculo de saldo em < 70ms
6. Stack
7. Infra
8. Desafios Processar dinheiro exige precisão. Escala exige consistência. Fazer os dois ao mesmo tempo… exige arquitetura.
9. A Realidade Milhares de transações por segundo. Saldos que não podem errar. Usuários impacientes. O sistema não pode falhar.
10. Estratégia 01 02 03 Transações atômicas Saldo baseado em Ledger Reconciliação financeira
11. O Ledger Tudo começa pelo Ledger. Cada entrada é uma verdade. Não se edita. Não se apaga.
12. Como não escalar user_id created_at idempotency amount description 4455 12:34:57 123 100 CASHIN 4455 12:35:59 124 50 CASHOUT 4455 12:36:41 125 100 CASHIN 4455 12:37:41 126 40 CASHOUT user_id balance 4455 0 4456 210 4457 450 4458 1.001
13. user_id created_at idempotency amount description 4455 12:34:57 123 100 CASHIN 4455 12:35:59 124 50 CASHOUT 4455 12:36:41 125 100 CASHIN 4455 12:37:41 126 40 CASHOUT user_id balance 4455 100 4456 210 4457 450 4458 1.001 Como não escalar
14. user_id created_at idempotency amount description 4455 12:34:57 123 100 CASHIN 4455 12:35:59 124 50 CASHOUT 4455 12:36:41 125 100 CASHIN 4455 12:37:41 126 40 CASHOUT user_id balance 4455 50 4456 210 4457 450 4458 1.001 Como não escalar
15. user_id created_at idempotency amount description 4455 12:34:57 123 100 CASHIN 4455 12:35:59 124 50 CASHOUT 4455 12:36:41 125 100 CASHIN 4455 12:37:41 126 40 CASHOUT user_id balance 4455 150 4456 210 4457 450 4458 1.001 Como não escalar
16. user_id created_at idempotency amount description 4455 12:34:57 123 100 CASHIN 4455 12:35:59 124 50 CASHOUT 4455 12:36:41 125 100 CASHIN 4455 12:37:41 126 40 CASHOUT user_id balance 4455 110 4456 210 4457 450 4458 1.001 Como não escalar
17. UPDATE balance = balance + amount
18. Concorrência Transação 1 Transação 2 [Leitura] saldo = 100 [Calcular] saldo - 10 = 90 [Leitura] saldo = 100 [Gravação] saldo = 90 [Calcular] saldo - 10 = 90 [Gravação] saldo = 90 T1 T2 T3 T4
19. Concorrência Transação 1 Transação 2 [Leitura] saldo = 100 [Calcular] saldo - 10 = 90 [Leitura] saldo = 100 [Gravação] saldo = 90 [Calcular] saldo - 20 = 80 [Gravação] saldo = 90 T1 T2 T3 T4
20. Solução Lock pessimista: trancar a linha do saldo (SELECT FOR UPDATE) Retry com optimistic locking Fila de transações com distribuited lock. No final você fica preso em uma escala linear
21. user_id created_at idempotency debit credit balance 4455 12:34:57 123 0 100 100 4455 12:35:59 124 50 0 50 4455 12:36:41 125 0 100 150 4455 12:37:41 126 40 0 110 O Ledger Tradicional
22. user_id created_at idempotency amount description 4455 12:34:57 123 100 CASHIN 4455 12:35:59 124 -50 CASHOUT 4455 12:36:41 125 100 CASHIN 4455 12:37:41 126 -40 CASHOUT Nosso Ledger
23. Mas onde fica salvo o saldo?
24. Saldo = D(-1) + Sum(amount)
25. Mas isso escala ... O saldo do dia anterior é cacheado. As transações do dia são poucas, comparadas ao histórico completo. O acesso é sequencial e indexado. Se escalar mais, basta adicionarmos mais snapshot.
26. Mas como a infra acompanha a escala?
27. Kubernets Microserviços
28. Kubernets Microserviços
29. Kubernets Microserviços
30. ECS Monolito
31. O poder do auto scaling ECS Fargate Aurora Serverless Lambda functions
32. Conclusão Cuidado com concorrência. Tenha um ledger desde o dia zero. Escalar é complexo. Investir em uma boa arquitetura, poupa problemas futuros.
33. Artigos: Por que escolhi AWS ECS para uma fintech e não o Serveless Certificados RSA e a Segurança na 3XPay Resolvendo Problemas de Performance com Redis e Bull Garantindo a Integridade de Dados em Transações Financeiras: A Solução com Transações no PostgreSQL ACID Transactions em uma Aplicação Fintech Migrando do RDS PostgreSQL para Aurora Serverless
34. Obrigado pela atenção! • r.avelarcampos@gmail.com • (31) 99202-7561 • @rafael.avelar