Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Como o iFood usou CQRS para escalar a contabilização de +30M de pedidos por mês - TDC Florianópolis 2020

379 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • Sé el primero en comentar

Como o iFood usou CQRS para escalar a contabilização de +30M de pedidos por mês - TDC Florianópolis 2020

  1. 1. Como o iFood usou CQRS para escalar a contabilização de +30M de pedidos por mês
  2. 2. Danilo P. De Luca Software Engineer - iFood Fintech Team Quem sou eu? /danilopereiradeluca /danilopdl
  3. 3. +30M pedidos mês +160K restaurantes ativos Arquitetura MicroService Cenárioatual doiFood
  4. 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. 5. Repasses aos restaurantes
  6. 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. 7. Detalhes distribuídos em +15 serviços
  8. 8. Payout- service billing- framew ork billing- gmv Billing- Order billing- occurre nce billing- fee
  9. 9. 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
  10. 10. 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”
  11. 11. ● 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.
  12. 12. Utilizando CQRS e +Event-Driven(Sagas)
  13. 13. 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?
  14. 14. O que é CQRS? fonte: https://martinfowler.com/bliki/CQRS.html
  15. 15. 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
  16. 16. Sagas Pattern fonte: https://microservices.io/patterns/data/saga.html
  17. 17. Possíveis implementações 1. Replicação de Banco de Dados. 2. Utilização de broker de mensageria (SQS/SNS/KAFKA)
  18. 18. ● 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.
  19. 19. Replicação de dados por Banco de Dados.
  20. 20. ● 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
  21. 21. ● 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
  22. 22. Utilização de broker de mensageria - Kafka
  23. 23. Utilização de broker de mensageria - Kafka
  24. 24. ● 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”
  25. 25. 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
  26. 26. 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
  27. 27. Referências
  28. 28. Referências http://cqrs.nu/ https://martinfowler.com/bliki/CQRS.html https://microservices.io https://www.confluent.io/blog/category/microservices/
  29. 29. Dúvidas? #Fi queEmCasa

×