Connecting 60k+ Restaurants: iFood's Architectural Saga
summary
This talk describes iFood’s event-orchestration architecture that scales notifications between the app and over 60,000 restaurants, handling 17 million monthly orders. It explains migrating from a monolith to multiple microservices and the use of Apache Ignite (distributed in-memory SQL cache) and Redis (single-threaded key-value cache), why AWS Kinesis for real-time ingestion did not fit their needs, and how IoT and restaurant-side changes helped deliver 98% of events within 45 seconds.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 2:26Order flow challenges
- 5:57Architecture evolution since 2012
- 7:40First app and Connect team
- 9:26Current architecture overview
- 12:16Connection service functions
- 15:50State and connectivity validation
- 18:16Apache Ignite and state management
- 21:48Polling service issues and fixes
- 24:14Restaurant devices transformation
- 26:01Client architecture and resilience
- 28:3398% orders under 5 seconds impact
- 31:29Results and 300k restaurant expansion
- 33:15Simplicity and optimization culture
- 35:20Writing and reading service lessons
- 36:42Working at iFood
related talks
38mData Management with Microservices and iFood's Experience
34mMicro-services for a Billion people
38mCloud Microservices to Serve the Next Billion
21mDelivering Digital to a Fast Food Company
29mUnveiling Resilience: iFood's Jenga & Sherlock Holmes Practices in Chaos Engineering
51mCompetitive retail architecture with microservices
51mEffective Microservice Communication and Conversation Patterns
19mDoorDash Diaries: Mastering Microservices at Mega Scale