iFood architecture visualization
All architectures
Technical deep dive

iFood

How iFood connects streaming events, a lakehouse, and machine learning to power food delivery.

Numbers that matter

65M+
Orders / month
Historical Databricks case study
10,000
Simulations / month
Databricks case study
67%
Pipeline cost reduction
Reported migration scope only
70%
Maintenance reduction
Declarative pipelines case study

The stack

Databricks· data and ML platform
Kafka· event streaming
Delta Lake· transactional lake tables
AWS· cloud infrastructure
Amazon S3· lake storage
Amazon Kinesis· streaming ingestion
Apache Spark· batch and streaming compute
Apache Airflow· workflow orchestration
Feature platform· offline and online ML features

The architecture as an interactive dashboard

The idea is simple: learn by reading the diagram. Every box and arrow tells part of the story — click to open.

How to read this diagram
Boxes = components

Color signals the role: client, streaming, storage, compute, ML, serving. Click any box to see what it is, why it's used, and what happens there.

Arrows = data flow
streaming· live eventsbatch· scheduled jobsync· direct callserve· user-facing
Click any step to explore
Apps + service…Clientclick →
Kafka / Kinesi…Streamingclick →
Spark / Databr…Computeclick →
AirflowComputeclick →
Delta Lake / S…Storageclick →
Feature platfo…MLclick →
Analytics + tr…Computeclick →
ML decisionsServingclick →
Conceptual synthesis of public iFood talks and case studies across platform generations — logical responsibilities, not a verified deployment map.
Optional
Read the full written deep dive
The same ideas as the diagram, with more context — recommended after exploring the steps.

Streaming events and orchestrated workflows solve different problems

Order and delivery updates matter to many consumers. Event streaming lets producers publish changes without owning every analytics or ML workload downstream.

Airflow orchestrates workflows; it is not the per-event transport. Separate continuous ingestion from scheduled recomputation, and define replay, deduplication and late-data policies explicitly.

The lakehouse as a reusable historical foundation

iFood's feature-store material connects Spark, Databricks and Delta tables: one durable history for processing, offline features and analysis, instead of separate extracts per consumer.

A newer Databricks case study reports 67% lower processing and storage costs and 70% less maintenance after moving pipelines to declarative pipelines — results of that initiative, not universal promises.

Features connect historical learning to live decisions

Documented ML uses include restaurant and dish recommendations, delivery-time estimation and courier allocation. A prediction is an input to a decision, not the whole decision system.

Treat freshness, entity keys and historical meaning as part of each feature's contract, so offline training and online serving agree.

Simulation complements production dispatch

The Databricks and Tableau story describes a simulator for testing business hypotheses before production changes — 10,000 simulations in a single month.

That loop differs from live courier assignment: simulation evaluates possible policies; operational services act on current conditions. Keep both connected without confusing them.

Curated sources

The public sources behind this analysis, with our take on why each one is worth your time.

Learn what makes this work

The DataForge courses that cover the pieces of this architecture.

Last updated:
← See all architectures