iFood: de 1 milhão de pedidos por mês a eventos para 60 mil restaurantes

01 · CONTEXTO

Um pedido que vira eventos para os restaurantes

Segundo o resumo de uma palestra publicada no InfoQ Brasil, a cada um dos 17 milhões de pedidos mensais gerados no aplicativo do iFood, eventos são gerados e enviados para os mais de 60 mil restaurantes. O time responsável por essa parte, chamado Connection, é descrito como de alta criticidade para a solução.

1. O diagrama começa no aplicativo, onde o pedido é gerado.

2. Cada pedido gera eventos; no diagrama, esse papel fica num bloco de geração e envio de eventos.

3. Os eventos são enviados aos restaurantes parceiros.

O diagrama mostra apenas o fluxo descrito no resumo. Este caso não afirma como o envio é implementado por dentro.

02 · DESACOPLAR

Dos pipelines em lote aos eventos

Segundo a Confluent, depois do crescimento e da expansão rápida das operações em 2016, o iFood percebeu que precisava escalar e levar para a nuvem as operações de back-end hospedadas em data center. As oscilações de demanda, como os picos de almoço e jantar no domingo, também contribuíram para a decisão, porque a elasticidade da nuvem poderia atendê-las.

No desenho anterior, bancos, serviços e aplicações estavam fortemente acoplados e usavam pipelines em lote para mover dados entre os sistemas. Um erro simples em qualquer serviço afetava outros serviços, e achar a origem do erro consumia muito tempo.

1. Serviços e bancos aparecem fortemente acoplados.

2. Um pipeline em lote move dados entre os sistemas.

3. Um erro simples num serviço afeta outro serviço.

Para resolver esses problemas, o iFood decidiu adotar o Apache Kafka. Sem recursos e experiência para operá-lo por conta própria, começou pelo AWS MSK, o Kafka gerenciado da AWS, para criar pipelines de dados em fluxo que monitoram pedidos e acompanham entregas.

Mesmo nesse serviço gerenciado, as equipes de dados e de plataforma passaram a gastar a maior parte do tempo em tarefas operacionais, como dimensionar clusters e planejar capacidade. O iFood decidiu então migrar para o Confluent Cloud, um serviço Kafka totalmente gerenciado.

Segundo a Confluent, o iFood construiu pipelines de dados em fluxo entre 2.000 microsserviços, o que permitiu desacoplar a arquitetura legada e adotar uma arquitetura orientada a eventos.

1. Microsserviços trocam dados por pipelines em fluxo: no diagrama, um produtor publica no Kafka gerenciado e um consumidor lê dele.

2. O ksqlDB roda processamento de fluxo sobre os dados em tempo real.

3. O resultado do processamento serve para monitorar a quantidade de pedidos na plataforma.

4. Pipelines em fluxo também levam os dados a um data lake na AWS, usado em análises e aprendizado de máquina.

03 · EXECUÇÃO

De instâncias sob demanda ao Kubernetes

Em outra palestra, cuja página a associa ao QCon São Paulo 2019, o iFood relata a transição de um ecossistema baseado em instâncias on-demand para a orquestração de containers via Kubernetes, em um serviço que processa mais de 20 milhões de registros por dia.

O resumo da palestra também menciona as limitações encontradas em serviços como AWS Lambda e DynamoStream. Este caso não afirma quais foram essas limitações nem como foram contornadas.

04 · CLUSTERS GERENCIADOS

Do Kubernetes autogerenciado ao EKS

Em um estudo de caso publicado pela AWS, o iFood relata que iniciou a migração de sua infraestrutura autogerenciada do Amazon EC2 Kubernetes para o Amazon EKS.

O estudo conta que os clusters produtivos saíram de 10 ou 12 em 2020 para 40 e que, com os ambientes de homologação, chegaram a cerca de 60. Para um time de apenas nove pessoas, era muita coisa para gerenciar manualmente.

No Faster, unidade voltada à análise de perfil de usuários, a média era de 20 milhões de requisições por minuto, com 60 milhões nos picos, e o ambiente chegou a ter um cluster com mais de 1,5 mil nodes no ar.

1. As requisições dos usuários chegam à carga do Faster.

2. Essa carga rodava num cluster que chegou a ter mais de 1,5 mil nodes.

3. O diagrama mostra o EKS, serviço gerenciado que, segundo o iFood, cuida da parte mais complexa do Kubernetes.

A escolha pelo EKS veio, segundo um SRE do iFood, porque a empresa já estava na AWS e já tinha decidido não mais gerenciar a parte mais complexa do Kubernetes.

A migração começou de fato em março de 2025 pelo cluster do Faster, concluída em setembro do mesmo ano. A expectativa registrada no estudo era migrar toda a infraestrutura até outubro de 2026.

05 · LIÇÕES E LIMITES

O que este caso mostra e o que não mostra

Em duas das fontes aparece um motivo parecido: carga operacional sobre equipes pequenas. Na Confluent, as equipes de dados e de plataforma gastavam a maior parte do tempo em tarefas operacionais como dimensionar clusters e planejar capacidade; no estudo da AWS, um time de apenas nove pessoas tinha muita coisa para gerenciar manualmente.