Nessa talk abordaremos como as diversas abordagens de arquiteturas distribuídas têm contribuído com a evolução dos produtos do mercado financeiro. Além disso, apresentaremos cases dos times de engenharia da XP Inc sobre análise, modelagem e desenvolvimento de sistemas robustos, disponíveis e escaláveis.

1. TDC Future - Arquitetura
Abraçando a variedade de
padrões de arquiteturais distribuídos
para resolver problemas de produtos financeiro

2. 2
2
PALESTRANTES
FABIO RAZZO GALUPPO
MSc. em Ciência da Computação
Esp. em arquitetura e desenvolvimento de software
WILSON BREDA
Bacharel em sistemas de informação
Staff Software Engineer
YAN JUSTINO
MSc. Software Engineer
Senior Software Engineer

3. 3
3
AGENDA
Escalabilidade
Microservices and containerization patterns
Idempotência
Bloom filter approach
Observabilidade
High Dynamic Range Histogram
Alta disponibilidade
Actor Models

4. CONTEXTUALIZAÇÃO
Visão Geral

5. Sistema Financeiro
[software system]
Contexto
Cliente
Container
Mobile
[Technology]
Gerenciador de
Ordens (OMS)
[container]
* Latência
Gerenciador de Saldo
do Cliente
[container]
Consistência e
disponibilidade
Sistema de
Negociação
[container]
Latência
Gateway de
entrada de ordem
[container]
* Latência

6. 6
6
ESCALABILIDADE
Microservices and containerization patterns

7. PROBLEMA
Como lidar com o acoplamento de implementação e a concorrência de implantação e,
além disso, proporcionar maior flexibilidade e abertura para decisões futuras?
Número de engenheiros ultrapassa a ordem de grandeza das centenas.
Complexidade da aplicação cresce constantemente
Necessidade de vários testes para garantir que alterações não compromentam a integridade de todo Sistema.
Alta concorrência na implantação

8. SOLUÇÃO
Com a arquitetura de microsserviços, uma aplicação pode ser facilmente escalada
tanto horizontalmente quanto verticalmente, a produtividade e a velocidade aumentam
e tecnologias podem ser facilmente trocadas pelas mais recentes.
Modelagem em torno de um domínio de negócio.
Menor interface possível
Propriedade sobre os próprios dados
Autonomia, escala (de serviços e time), diversificação tecnológica.

9. APLICAÇÃO
Gateway
[container]
Topic 1
Gerenciador de Ordens
(OMS)
[container]
Gerenciador de Saldo
do Cliente
[container]
Topic 2
Sistema de
Negociação
[container]
Topic 3
Topic 4
Topic 4
Topic 6

10. APLICAÇÃO
Gateway
[container]
Topic 1
Gerenciador de Ordens
(OMS)
[container]
Gerenciador de Saldo do
Cliente
[container]
Topic 2
Sistema de Negociação
[container]
Topic 3
Orchestration
[container]

11. 11
11
QUANDO MSA NÃO SERIA UMA
BOA IDEIA
Quando o Domínio de negócio é
Nebuloso
Startups em fase inicial no
processo de evoluçÃo
Software instalado e administrado
pelo cliente
Não ter um bom motivo para adotar
microsserviços

12. 12
12
IDEMPOTÊNCIA
Bloom Filter Approach

13. PROBLEMA
Mensagens não podem ser perdidas, principalmente se for uma importante para o negócio.
Garantir a entrega de mensagens pelo menos uma vez é fundamental, mesmo se ocorrerem erros durante a
entrega. Nesse caso, o produtor pode retransmitir a mensagem na presença de um falso negativo como status da
entrega
Por consequência, o consumidor deve ser idempotente e saber lidar com o recebimento de mensagens repetidas.
Por exemplo, uma ordem de compra de um ativo, em forma de mensagem, não deve ser registrada duas vezes no
sistema
Como implementar um consumidor que trate as mensagens duplicadas corretamente?
13

14. SOLUÇÃO
As partes envolvidas na troca de mensagem adotam um campo sequencial numérico para controle de
idempotência. Ex.: MsgSeqNum (34) no protocolo FIX
O consumidor registra um identificador da mensagem processada com êxito num banco de dados para consultar
posteriormente. Ex.: MessageID é um UUID usado para identificar a mensagem
O consumidor utiliza uma estrutura de dados probabilística em memória para minimizar a consulta do identificador
no banco de dados. Ela pode gerar falsos positivos, quando isso acontecer é necessário consultar o banco de
dados. Ex.: Bloom Filter para controlar o MessageID
A solução consiste na implementação de um consumidor idempotente que deve
identificar e tratar de forma adequada as mensagens repetidas – pode-se ignorar ou
rejeitar a mensagem duplicada. Algumas possibilidades:
14

15. APLICAÇÃO
Consumidor Idempotente
[Container]
Container
[Technology]
Mensagem
Enviada
Mensagem
Rejeitada
Mensagem
processada
Bloom Filter
[componente]
15

16. 16
16
Demos

17. 17
17
OBSERVABILIDADE
High Dynamic Range Histogram

18. PROBLEMA
Garantir as atividades e a saúde do sistema, bem como detectar e reagir em aos problemas
(troubleshooting) é um dos principais fatores para incluir algum nível de observação. Entre eles estão:
Métricas (CPU, Memória, msgs/s etc);
Agregação de logs;
Logs de auditoria;
Rastreamento de operação;
Rastreamento de exceção;
Health check.
Como medir o Round-trip Time (RTT) corretamente? O que será extraído através
dessa medição?
18

19. SOLUÇÃO
Para coletar o RTT das mensagens do sistema, é necessário a implementação de pontos específicos de medição,
onde serão coletados os timestamps inicial e final de um bloco de processamento. Com isso, será obtido como
métrica a latência do envio e recebimento de mensagens do sistema.
Os timestamps podem ser registrados num banco de dados (por exemplo, time-series db). Com esses dados será
gerado um histograma na ordem crescente e dividido em 100 partes, os percentis. O percentil 99 indicará o maior
tempo do RTT considerando 99% das amostras ordenadas, ou seja, 1% dos piores tempos medidos serão
desconsiderados.
19

20. Application
[Container]
APLICAÇÃO
Resposta
Recebida
HDR Histogram
[componente]
Handler
[componente]
Requisição
Enviada
20

21. 21
21
Demos

22. 22
22
ALTA DISPONIBILIDADE
Actor Model

23. PROBLEMA
Com a consolidação de tecnologias como o Docker e Kubernetes, quando falamos de escalabilidade logo pensamos
em escalabilidade horizontal.
Para realizarmos essa escalabilidade de forma segura, é recomendado que trabalhemos com sistemas stateless.
Mas e se quisermos guardar o estado de uma determinada entidade? Base de dados:
SQL
Cache Distribuído
NoSQL
Problemas para sistemas onde a quantidade de requisição e o tempo de processamento de cada requisição deve ser
baixo, uma vez que escalar essas bases é complexo (e caro)
Racing Conditions
Deadlock
Como obter alta disponibilidade de uma única entidade sem impactar o custo e a
complexidade de infraestrutura?
23

24. SOLUÇÃO
Modelo de atores foi criado por Carl Hewitt em 1973 e Possui as seguintes características:
Comunicação entre os atores com mensagens imutáveis
Single Thread
Cada ator é único para o sistema
Criação de sistemas statefull, onde:
Cada ator mantem seu próprio estado em memória
Lock-free: uma vez que eles são single thread e processam uma mensagem por vez
Capacidade de escalonamento entre as máquinas do cluster
Exemplo de tecnologias que facilitam a criação de sistema baseado em modelo de atores:
Erlang, Akka,,ReActed, Cloudi, Proto.Actor, Microsoft Orleans, Dapr
24

25. Cluster
[Software System]
APLICAÇÃO
A solução pode ser divida em três partes
Atores
único e responsável pela lógica de negócio
Cluster
conjunto de máquinas onde os atores serão
hospedados e seu ciclo de vida gerenciado.
Cliente
aplicação que irá solicitar uma determinada
funcionalidade a um ator
Node
[Container]
Base
Clientes
Node
[Container]
Node
[Container]
Node
[Container]
Cliente
[Container]
25

26. 26
26
Obrigado!