iFood: Connecting 60k+ Restaurants - A Foodtech Saga

1. Conectando +60k restaurantes A saga arquitetural do iFood

2. Objetivo

3. O iFood A foodtech mais legal de LATAM

6. Os problemas Enviar pedidos para restaurantes online, quão difícil pode ser?

7. Fluxo básico • Cliente faz o pedido pelo app. • Restaurante recebe o pedido, confirma-o, e começa a preparar. • Após o preparo, o pedido é entregue ao cliente, seja via um entregador do restaurante ou do iFood.

8. A arquitetura mais simples

10. Então, como?

11. Atualmente...

12. Timeline

13. E no começo, era tudo assim

14. E aí, fax!

15. Surgiu isso, logo após

16. < 2012

17. Desktop!

18. Bons tempos

19. Triplo de tamanho, o triplo da treta

20. Pró-ativamente entregando pedidos

21. Pró-ativamente entregando pedidos v2.0.0

22. Hoje

24. Ponto de entrada do sistema. A ponta entre outros sistemas do iFood e Connection Qual o papel do serviço • Converte do formato externo para o formato interno • Configuração de serviços usados internamente • Produz eventos em tópicos/filas separados, poderia ser melhor Gateway Agent

25. Serviço chave, mini-monolito. Atualmente sendo quebrado em microsserviços. Qual o papel do serviço • Polling de eventos de integrações legadas (não é muito importante hoje) • Controle de dispositivos de um restaurante • Validação da transição do status do pedido (chave) Nada acontece no iFood sem esse serviço. Gateway Core

26. Controla o status de conectividade atual do restaurante, em memória, em um cache em memória Qual o papel do serviço • Processa os heartbeats (chamada do polling) recebidos pela API do Kitchen, indexando-os em memória • A cada 5s roda um MapReduce no cluster transicionando os restaurantes de ONLINE para OFFLINE • Essa transição escreve uma nova entrada no banco que é “syncado” com um banco de busca Merchant Connection

29. Mantém os eventos do momento em memória, num cluster de Apache Ignite Qual o papel do serviço • Indexa em memória os eventos validados pelo Core • É o serviço primário de polling atualmente do iFood Order-Events

32. Coleção de microsserviços embaixo de um API Gateway Kitchen Polling Responde às rotas de polling, conhece os serviços de polling primário e o fallback Kitchen Connection Responde às rotas críticas relacionadas ao pedido: detalhes, integração, confirmação, etc Kitchen Endpoint Responde às rotas não-críticas relacionadas ao pedido: configurações, SKUs, etc Kitchen API

33. Fallback do polling, entra em ação quando o serviço primário (order-events) não está disponível Qual o papel do serviço Lê os pedidos atuais do DynamoDB. Pedidos são indexados lá através de lambdas pendurados no tópico do Gateway Core. Connection Polling

35. Broker MQTT. Entrega de forma pró-ativa os pedidos. Qual o papel do serviço • Gestor (app client do restaurante) conecta diretamente no Broker • Um lambda recebe do tópico do Core e faz uma publicação no tópico • Em caso de desastre, o fallback do client é o polling • Existe uma lógica para usar o polling primeiro e depois conexão persistente • Existe um sync lógico entre MQTT e Merchant Connection através do SNS EMQX MQTT Broker

38. < 40k!

40. Mas com um custo...

41. Conclusão

42. Otimizar escrita vs leitura

43. Monolito = bad (mas nem sempre)

44. O iFood é hoje o melhor lugar para se trabalhar com dev porque...