Nesta palestra pretendo falar uma das estratégias que tivemos para diminuir problemas na informação de pagamento das vendas de mais de 23 milhões de pedidos/mês divididos em mais de 120mil restaurantes, chegando a ser um dos principais tópicos de contact rate do Ifood. Uma das estratégias foi alterarmos quase todo modelo de dados em mais de 15 micro serviços distintos e como mitigar problemas na concorrência entre uma camada voltada para processamento de mais de 23 milhões de eventos em curtas janelas de tempo e outra camada de consulta de informações financeiras

1. Como o iFood usou
CQRS para escalar a
contabilização de +30M
de pedidos por mês

2. Danilo P. De Luca
Software Engineer - iFood
Fintech Team
Quem sou eu?
/danilopereiradeluca
/danilopdl

3. +30M pedidos mês
+160K restaurantes ativos
Arquitetura MicroService
Cenárioatual
doiFood

4. ● Dinâmicas de precificação de pedido.
● Repasses/Transferências aos restaurantes.
● Fechamento contábil do iFood.
O que o time de Fintech
faz?

5. Repasses aos
restaurantes

6. ● Detalhes distribuídos +15 serviços.
○ Agregações de dados.
● Concorrência de processamento x
consulta.
● Modelo de visualização “acoplado”.
● Escalabilidade e Performance.
● Difícil manutenção.
Nossos problemas

7. Detalhes distribuídos em +15 serviços

9. Payout-
service
billing-
framew
ork
billing-
gmv
Billing-
Order
billing-
occurre
nce
billing-
fee

10. Os mesmos serviços que tinham a
responsabilidade de fazer o processamento
pesado para garantir o valor correto de repasse,
tinham que “concorrer” com uma camada de
consulta.
Em dados momentos os serviços degradavam
pela quantidade de consultas ser intensa e o
processamento acabava sendo afetado.
Concorrência de
Processamento X Consulta

11. Acoplamento com o modelo usado para salvar
os dados processados com o modelo de
consulta, dificultando evolução em ambos os
modelos.
Além disso, a mudança em um sistema refletia
na mudança de todos os sistemas que faziam
consulta aos dados desse sistema.
Modelo de visualização “acoplado”

12. ● Alto custo de escalabilidade, tanto para
aplicação quanto para banco de dados,
tendo um retorno de resposta não
satisfatório.
● Performance limitada a performance de
query (indexes).
Escalabilidade e Performance
Difícil manutenção
Alteração em 1 serviço exigia deploy em
outros serviços, principalmente quando
mudava o modelo de dados.
Configuração de backpressure de
processamento depender do throughput
de consulta.

13. Utilizando CQRS e
+Event-Driven(Sagas)

14. CQRS (Command Query Responsability
Segregation) é um pattern de arquitetura
que resume a separação da arquitetura em
duas camadas: uma de leitura e uma de
comandos (escrita). Com isso é possível ter
modelos diferentes na camada de consulta
da camada de escrita/update.
O que é CQRS?

15. O que é CQRS?
fonte: https://martinfowler.com/bliki/CQRS.html

16. Sagas Pattern
Event-Driven
“Uma forma de dividir uma transação
distribuída em um conjunto de transações
menores em qualquer commit ou rollback.”
- Chris Richardson
**Garantia de ACID - Atomicidade,
Consistência, Isolamento e Durabilidade

17. Sagas Pattern
fonte: https://microservices.io/patterns/data/saga.html

18. Possíveis implementações
1. Replicação de Banco de Dados.
2. Utilização de broker de mensageria
(SQS/SNS/KAFKA)

19. ● Utilização de mecanismos e rotinas
de banco de dados para replicação
de dados em outra base.
● Criação de “Views” para agregação
de dados e assim termos os dados
já modelados para facilitar queries.
Replicação de dados por Banco de Dados.

20. Replicação de dados por Banco de Dados.

21. ● Performance limitada a indexação
nas queries
● Alta complexidade na criação das
views
● Pouca flexibilidade para evolução
● Custo com infra muito alto - Banco
de dados gigante
Replicação de dados por Banco de Dados.
Problemas

22. ● Utilização de broker de mensageria
para internalização de dados.
● Modelagem de dados a partir de
“views” específicas.
● Possibilidade de utilizar um banco
diferente para consulta de dados -
ScyllaDB.
Utilização de broker de mensageria - Kafka

23. Utilização de broker de mensageria - Kafka

24. Utilização de broker de mensageria - Kafka

25. ● Mais um step em todos as Sagas
dos serviços para publicação de
dados no broker.
● Complexidade na orquestração de
eventos.
● Reprocessamento das “views” ser
unitário.
Utilização de broker de mensageria - Kafka
“Problemas”

26. 1. +1 step de complexidade
nas sagas.
2. Um novo sistema para
monitoramento.
3. Único ponto de “query”
para clients.
4. Custo de implementação.
Principais problemas usando CQRS

27. 1. Performance nas APIs de consulta
2. Maior escala em processamento de
dados.
3. Escalabilidade voltada ao problema.
4. Menor tempo de indisponibilidade
durante grandes processamentos.
5. Desacoplamento de dados
Benefícios usando CQRS

28. Referências

29. Referências
http://cqrs.nu/
https://martinfowler.com/bliki/CQRS.html
https://microservices.io
https://www.confluent.io/blog/category/microservices/

30. Dúvidas?
#Fi queEmCasa