iFood: from 1 million orders a month to events for 60 thousand restaurants

01 · CONTEXT

An order that becomes events for restaurants

According to the summary of a talk published on InfoQ Brasil, for each of the 17 million monthly orders generated in the iFood app, events are generated and sent to the more than 60 thousand restaurants. The team responsible for this part, called Connection, is described as highly critical to the solution.

1. The diagram starts at the app, where the order is generated.

2. Each order generates events; in the diagram, this role sits in an event generation and sending block.

3. The events are sent to partner restaurants.

The diagram shows only the flow described in the summary. This case does not state how the sending is implemented internally.

02 · DECOUPLING

From batch pipelines to events

According to Confluent, after the rapid growth and expansion of operations in 2016, iFood realized it needed to scale and move the back-end operations hosted in a data center to the cloud. Demand swings, such as Sunday lunch and dinner peaks, also contributed to the decision, because cloud elasticity could handle them.

In the previous design, databases, services, and applications were tightly coupled and used batch pipelines to move data between systems. A simple error in any service affected other services, and finding the source of the error took a lot of time.

1. Services and databases appear tightly coupled.

2. A batch pipeline moves data between the systems.

3. A simple error in one service affects another service.

To solve these problems, iFood decided to adopt Apache Kafka. Without the resources and experience to operate it on its own, it started with AWS MSK, AWS's managed Kafka, to create streaming data pipelines that monitor orders and track deliveries.

Even with this managed service, the data and platform teams started spending most of their time on operational tasks, such as sizing clusters and planning capacity. iFood then decided to migrate to Confluent Cloud, a fully managed Kafka service.

According to Confluent, iFood built streaming data pipelines across 2,000 microservices, which made it possible to decouple the legacy architecture and adopt an event-driven architecture.

1. Microservices exchange data through streaming pipelines: in the diagram, a producer publishes to managed Kafka and a consumer reads from it.

2. ksqlDB runs stream processing over the data in real time.

3. The processing result is used to monitor the number of orders on the platform.

4. Streaming pipelines also carry the data to a data lake on AWS, used for analytics and machine learning.

03 · EXECUTION

From on-demand instances to Kubernetes

In another talk, whose page associates it with QCon São Paulo 2019, iFood reports the transition from an ecosystem based on on-demand instances to container orchestration via Kubernetes, in a service that processes more than 20 million records per day.

The talk summary also mentions the limitations found in services such as AWS Lambda and DynamoStream. This case does not state what those limitations were or how they were worked around.

04 · MANAGED CLUSTERS

From self-managed Kubernetes to EKS

In a case study published by AWS, iFood reports that it began migrating its self-managed Amazon EC2 Kubernetes infrastructure to Amazon EKS.

The study says production clusters went from 10 or 12 in 2020 to 40 and that, with staging environments, they reached about 60. For a team of only nine people, that was a lot to manage manually.

At Faster, a unit focused on user profile analysis, the average was 20 million requests per minute, with 60 million at peaks, and the environment once had a cluster with more than 1,500 nodes running.

1. User requests reach the Faster workload.

2. That load ran on a cluster that at one point had more than 1,500 nodes.

3. The diagram shows EKS, a managed service that, according to iFood, takes care of the most complex part of Kubernetes.

The choice of EKS came, according to an iFood SRE, because the company was already on AWS and had already decided to stop managing the most complex part of Kubernetes.

The migration actually began in March 2025 with the Faster cluster and was completed in September of the same year. The expectation recorded in the study was to migrate the entire infrastructure by October 2026.

05 · LESSONS AND LIMITS

What this case shows and what it does not

A similar reason appears in two of the sources: operational load on small teams. At Confluent, the data and platform teams spent most of their time on operational tasks such as sizing clusters and planning capacity; in the AWS study, a team of only nine people had a lot to manage manually.