What to Expect in the Flipkart System Design Interview

Flipkart grades design in two separate rounds, and the machine coding round comes first. Candidates report a machine coding round of 90 to 120 minutes where you build a small working program. Mid-level and senior candidates also report a discussion-based system design round of about 90 minutes, and some reports describe a longer session.

Reported design questions include a flight booking system, a rate limiter with and without Redis, and a notification service. The two rounds grade different things, because machine coding grades code that runs and the design round grades the discussion.

The Machine Coding Round

A machine coding round is a timed session where you build a small console application from a written requirement list, and candidates report 90 to 120 minutes, with some senior candidates reporting longer. Several reports say you use your own laptop and your own editor, and that the code must compile and run at the end.

Reported problems include a multi-level cache with get, set, and statistics commands, a food ordering system, a ride offer and ride share feature, an expense splitting application, and a library system with issue, return, and fine rules. The requirement list usually separates required features from bonus features, so finish the required ones first.

Interviewers grade four things: the program runs, the classes are separated by responsibility, invalid input is handled, and a new requirement can be added without a rewrite. Because this round is a low-level design exercise that must also compile and run, see system design versus low-level design for the difference between the two kinds of design question. For the format itself, what a machine coding round contains describes the same round at another company.

The Design Round Question Types

Booking and reservation systems. A flight booking design is reported directly, and this family tests seat or stock reservation, race conditions when two users take the last unit, and the hold and release cycle. It matches Flipkart's own inventory problem.

Rate limiting. A rate limiter is a part that rejects requests above an allowed rate, and one reported round asked for one both with Redis and without it, including the sliding window method. Expect questions on where the counter lives when there are many servers.

Notification systems. A reported question asks for a service that sends messages to customers, so expect fan-out, delivery across email, SMS, and push, retries, and deduplication.

Catalog, cart, and order flows. These follow Flipkart's product directly, so expect search over many sellers, a shared cart that does not lose concurrent updates, order state across partial cancellations, and returns.

A Walkthrough: Order Placement During a Sale Event

Here is a high level plan for the reservation family of questions.

1. Requirements (5 minutes). Many sellers, one catalog, and a demand spike concentrated into a few hours, under the non-negotiable rule that you never sell stock you do not have.

2. Read path. Product pages are read far more often than they are written, so serve them from a cache and a search index, and accept that the displayed stock count may lag slightly.

3. Reservation. At checkout, take a short-lived reservation on the exact units, using a single authoritative store for stock with a conditional update so two requests cannot both succeed. Release the reservation on a timer if payment does not complete.

4. Payment and order creation. Make the payment callback idempotent, which means a repeated callback produces the same result, and key it on the order identifier, because gateways retry.

5. Spike control. Queue order creation so the system slows down instead of failing, and apply rate limits per user and per product for high-demand items.

6. After the sale. Cancellations and returns put stock back, so model order state as explicit transitions, and a partial cancellation then stays correct.

What the Interviewer Grades

Reports describe interviewers who choose one part of your design and ask for detail until you can no longer answer, so state requirements before drawing anything and name each trade-off out loud. Connect choices to customers, because an oversell means a refund and a missed delivery promise. When a follow-up goes past what you know, say so plainly.

Common Mistakes in This Round

• Treating machine coding as an algorithm round. A clever algorithm with one large class scores poorly, because structure and extensibility are the grade.
• Skipping required features for bonus ones. Reports are consistent on this point, and incomplete required features fail the round.
• Ignoring concurrency. Two buyers and one unit of stock is the question, not a detail.
• Designing only the happy path. Failed payments, timeouts, retries, and cancellations account for most of the marks.
• No numbers. Estimate reads per second, writes per second, and storage before choosing a database.

How to Prepare

• Build the reported programs against a clock. Grokking the Object Oriented Design Interview covers the class designs these problems expect.
• Learn the building blocks. Grokking the System Design Interview covers caches, queues, and databases, which every answer above uses.
• See where the round sits. The full loop is in the Flipkart interview process, and the waits between rounds are in how long it takes to hear back.
• Tie the design to your motivation. The same product research answers why you want to work at Flipkart.