What to Expect in the iFood System Design Interview

Expect one round where the interviewer gives you a scenario and you design the architecture for it. Candidates report that the design stays at a high level, and that the interviewer then raises problems against it. iFood does not publish the scenarios, so the best preparation is the kind of system iFood actually runs.

That platform is event driven, which means services publish events and other services read those events independently. Public accounts from iFood engineers describe thousands of microservices connected by Apache Kafka, a system that stores streams of events. So this round rewards clear service boundaries, sensible event flows, and honest failure handling far more than unusual technology choices.

How the Round Runs

iFood does not publish a question list, and candidates describe a scenario given to them during the interview itself. Reports describe two technical interviewers who raise problems against the design while you present it. Expect questions about what breaks first, what happens during a traffic spike, and why you chose each database. Start by asking for the requirements, because the scenario is usually only one or two sentences long.

The Topics Candidates Report

• Service boundaries come up often in candidate reports. The monolith versus microservices question is common, and the answer that scores is a trade-off, not a preference.
• API and integration design is also reported. Expect questions about the contract between two services, about versioning, and about timeouts when one side is slow.
• Storage choices are tested directly. Say which data needs strict consistency and which data can be slightly stale, then pick a relational or non relational store for each.
• Kafka and event streaming appear often. Be ready to explain a topic, a partition, and what you do when a consumer falls behind the stream.

Where the Scenario Is Likely to Come From

iFood does not publish its design questions, so the list below is drawn from the parts of its business and from public accounts of its platform. Treat it as sensible preparation rather than a reported question list.

• The order lifecycle is the core problem. An order moves through placement, restaurant acceptance, preparation, pickup, and delivery, and every change produces an event other systems need.
• Assigning orders to couriers is a matching problem. The inputs are distance, expected timing, and the current load of each courier nearby.
• The restaurant side has its own needs. Restaurants need an order queue, status updates, and menu changes that reach customers quickly.
• Demand spikes are part of the business. Dinner time, rain, and promotions all raise traffic sharply within a few minutes.
• Grocery stores have large catalogs. A single store can list thousands of items, and the stock behind them changes constantly.
• Payments require exactly one charge. The system must charge the customer once per order, even when a mobile client retries the same request.

A Walkthrough: The Order and Delivery Flow

Here is a high level plan you can rehearse out loud.

Step 1: the requirements, about five minutes. Agree on millions of orders a day, a national courier network, live status for the customer, and no lost or duplicated order.

Step 2: the write path. The order service validates the cart and the address, charges the payment, and stores the order. Give each order a key supplied by the client, so that a retry cannot create a second order.

Step 3: the event backbone. The order service publishes one event for every state change, and pricing, dispatch, notifications, and analytics each read that stream at their own speed. This keeps teams independent, which matters when thousands of services exist.

Step 4: dispatch. A matching service reads nearby couriers from a geospatial index, which is a store that answers location queries quickly. It then scores candidates by distance, expected preparation time, and current load, and offers the delivery to the best one.

Step 5: live tracking. Courier positions arrive frequently and become stale within seconds. Keep the latest position in a fast in memory store and push updates to the customer, instead of writing every point into the main database.

Step 6: spikes and failure. Queue the work so that the system slows down instead of failing suddenly, cache menus and store pages, and make every consumer idempotent. Idempotent means that processing the same event twice gives the same result as processing it once.

What the Interviewer Grades

State the requirements before you draw anything, then name each trade-off out loud and say why you chose one side. Connect the choices to the business, because a late order loses a customer and a double charge makes customers stop using the app. Candidates report interviewers who challenge the proposal, so defend every part with a reason rather than a product name.

Common Mistakes in This Round

• Designing one large service for everything. The real platform is event driven, so a single database shared by every feature is the wrong answer here.
• Serving only the customer. Customers, couriers, and restaurants all have requirements, and a design that covers one of the three is incomplete.
• Forgetting duplicate protection. Mobile clients retry requests, and without idempotency those retries create double orders and double charges.
• Skipping the numbers. Estimate orders per second, event volume, and storage early, because that estimate decides every later choice.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and databases, which every delivery design uses.
• Go deeper on the hard cases. Advanced System Design Interview, Volume II helps with replication, partitioning, and failure handling.
• Rehearse the six steps above. Practice the order and delivery walkthrough out loud in under 40 minutes, without notes.
• See the full loop. The design round is one stage of the iFood interview process, next to the motivation question and the waits described in how long it takes to hear back.