Zomato System Design Interview: What the Bar Actually Tests

You have a restaurant. It just came back online after going dark for the weekend. Now you need to notify every user who favorited it, but only if a delivery partner is actually available near that restaurant right now. Not "roughly available" or "available somewhere in the city." Available in the geofence, right now, for that specific order radius.

Design that at Zomato's scale and you run headfirst into conditional fan-out, geospatial indexing, and distributed state that makes a simple "publish to Kafka, push notification, done" answer look like a child drew it. That is the kind of problem the Zomato system design interview surfaces. That is the calibration you need going in.

This guide covers the full loop: what rounds exist, what gets asked at each level, where candidates actually drop it, and how to prepare without spending six months in a bunker.

How the Loop Runs

Zomato runs three to four rounds for most engineering roles:

Round	What It Covers	Duration
Technical screening	DSA + project discussion	60 min
System design	HLD and/or machine coding (LLD)	60-90 min
Engineering manager	Culture, trajectory, judgment	45 min
Senior only: additional design	Broader architecture, cross-team scope	60 min

The system design round is round two in most loops. One consistent pattern from 2025 loops: Zomato interviewers explicitly penalize hedging. Circling a decision without committing reads as confusion, not caution. Make the call, state the tradeoff, move on.

Both Gates Are Real, and One Will Surprise You

Most Indian product companies treat HLD and LLD as separate creatures that live in separate forests. Zomato takes both seriously, and the balance shifts depending on your level.

At SDE-1, the design round is primarily HLD. You need to reason about microservices, databases, and async pipelines at a component level. Knowing when to reach for a relational store versus NoSQL, what message queues are actually for, and how a basic notification flow works will carry you through.

At SDE-2, things get uncomfortable. Documented 2025 interviews included a machine coding exercise for a Snake and Food Game alongside Redis internals and Kafka consumer throughput questions in the same session. You need to ship working code and reason about distributed systems inside the same 90 minutes. Many candidates preparing for FAANG loops underestimate how LLD-heavy this gets.

At senior, the question shifts from "can you design this" to "can you own this system for three years while it triples in load." The interviewer wants you to name failure modes before they ask, and justify technology choices with reasoning rather than vocabulary.

What They Actually Ask

Several questions appear repeatedly across documented Zomato interviews. These are not hypotheticals.

Restaurant reopen notification system. After a restaurant goes back online, Zomato wants to notify interested users, but only if delivery partners are available nearby. The candidate who draws a straight line from Kafka to push notification is not thinking about the gate check. The correct design: an event triggers, a service checks delivery partner coverage in the restaurant's geofence, then routes to the notification pipeline only if coverage clears. Queue otherwise. Retry when coverage resolves.

Rate limiter for an API gateway, optimized with Redis. Expected discussion: token bucket versus sliding window log versus sliding window counter, why Redis is the right store (atomic INCR, low latency, native TTL), and how you share rate limit state across multiple gateway nodes. A Lua script that atomically increments the counter and sets expiry in one round trip is the production pattern interviewers want to hear about.

Payments backend. Open-ended by design. The move that separates strong candidates is explicitly naming the CP/AP split: payments need strong consistency, restaurant browsing can tolerate eventual consistency. Treat them as separate services with different database choices. Saying "we could use either" here is a slow-motion exit.

Delivery partner location and assignment. How do you track 100,000-plus partners in real time and assign them to new orders? This gets into geospatial indexing (geohash, H3 hexagonal grids, quadtrees), Redis GEO commands for radius lookups, and a scoring function that weighs proximity against partner acceptance rate and current workload.

The Machine Coding Round Is Not a Warmup

At SDE-2, you have 60 to 90 minutes to design and implement a working system from scratch. No hints, no partial credit for good intentions.

Snake and Food Game. The constraint that matters: movement and collision detection must run in O(1). A deque handles the snake body (push head, pop tail on each move). A HashSet of occupied coordinates gives O(1) collision detection. The interviewer is checking whether you reach for the right data structure immediately or flail toward a 2D matrix scan and quietly sweat.

Food ordering system using State or Observer patterns. You model the order lifecycle: placed, restaurant accepted, preparing, ready for pickup, picked up, delivered, cancelled. The State pattern maps cleanly, with each transition as a method call, invalid transitions throwing, and side effects (notification dispatch, ETA recalculation) attached to transition hooks. The Observer pattern handles downstream listeners watching order events: analytics consumers, the customer app, the delivery partner app.

Both problems are solvable. What separates clean passes from rejections is how fast you reach for the right abstraction and whether the code actually compiles.

What Each Level Is Really Being Tested On

SDE-1. Can you design a system you have not built? The system does not have to be production-perfect. It needs to be coherent. If you cannot explain why async messaging beats direct HTTP calls for an order state change, you are at risk.

SDE-2. Can you build the component, not just draw it? The machine coding round is effectively pass/fail. Beyond that, you need real depth. Why is Redis fast? What causes consumer lag in Kafka and how do you fix it? How does SQL handle concurrent writes to the same order row? These questions surface whether you have debugged production issues or just read the documentation on a slow Tuesday.

Senior SDE. The interviewer is evaluating whether you are the person other engineers call when things break at 2 AM and everyone is panicking. Failure modes, schema migration paths, observability from day one. The conversation is less "design this" and more "show me you have thought about the life cycle of this system."

The Technical Surface You Must Own

Geospatial indexing. Geohash basics, H3 hexagons and their six equidistant neighbors, Redis GEORADIUS and GEOSEARCH. If you do not know what a geohash is, you have a gap worth closing before showing up.

Real-time order tracking. WebSocket connections for live status updates, SSE as a lower-overhead alternative for read-heavy flows, Kafka as the backbone that decouples order state changes from UI push.

Conditional notification fan-out. Routing based on multiple signals (delivery coverage, user preferences, quiet hours), idempotency keys to prevent duplicate sends, exponential backoff that does not hammer a recovering service.

Consistency in payments. Optimistic locking via a version column on the order row, idempotency keys on payment API calls, two-phase booking: soft hold, then confirm on payment success, compensating cancel on failure.

Rate limiting. Token bucket versus sliding window, Redis Lua scripts for atomicity, distributing rate limit state across multiple gateway nodes without creating a bottleneck.

Beyond the domain: consistent hashing, LSM-tree versus B-tree for write-heavy versus read-heavy workloads, Kafka at-least-once versus exactly-once delivery semantics.

How Candidates Drop the Loop

Leading with a tech stack. Do not open with "I would use microservices with Kafka and Redis." Start with requirements: peak order volume, acceptable read latency, consistency requirements for payments. Technology follows from constraints. Candidates who lead with tech and then find their choices do not fit look like they are pattern-matching, not designing.

Ignoring the hyperlocal domain. A generic notification answer that never mentions geofencing or delivery coverage misses the prompt entirely. Zomato's problems are geospatial and real-time. Read every question through that lens.

Hedging every decision. "We could use SQL or NoSQL, both have tradeoffs" is not an answer. It is a stall. Pick one, state the reason, acknowledge the tradeoff in a sentence, move on. Interviewers document this explicitly in feedback.

Skipping machine coding prep. A lot of candidates go deep on HLD and treat LLD as a formality. At SDE-2, the machine coding round does not care. Practice building systems with clean class hierarchies and compilable code under 90 minutes with a timer running and nobody helping.

Shallow Redis and Kafka knowledge. These two appear in nearly every SDE-2 interview. Know why Redis is single-threaded but fast (I/O multiplexing, in-memory data structures, no lock contention on the hot path). Know what consumer lag means, how to monitor it, and what you do when it spikes unexpectedly.

Four Weeks Is Enough If You Are Focused

Week one. Build the food delivery system end to end: restaurant discovery, ordering pipeline, delivery partner assignment, real-time tracking, notifications. The DoorDash system design walkthrough covers the same core architecture. Adapt it to Zomato's scale with geospatial awareness built in from the start.

Week two. Deep dive the two most common HLD questions: rate limiter and conditional notification system. Work through both from scratch, talking out loud. The rate limiter design walkthrough and the notification system design guide have detailed implementation patterns.

Week three. Two to three machine coding sessions under a timer. Snake game and food ordering state machine are the documented patterns. Build both. Aim for clean, compilable code by the 75-minute mark.

Week four. Full mock interviews, verbal. Explaining a system out loud is a completely different skill from designing it quietly on paper. SpaceComplexity runs AI-powered voice mock interviews where you walk through your architecture and get scored on design quality and communication. Most candidates know what to build. Fewer can defend it under live questioning without their hands starting to shake.

For calibration on how Zomato's bar compares to its closest competitor, the Swiggy system design interview guide covers a nearly identical loop with the same domain knowledge requirements.

What to Lock Down

Loop: three to four rounds, system design is round two at 60 to 90 minutes
SDE-1 faces HLD; SDE-2 faces both HLD and machine coding LLD
Documented HLD questions: restaurant reopen notifications with delivery coverage check, rate limiter with Redis, payments backend, delivery partner assignment
Domain knowledge is non-negotiable: geospatial indexing, real-time tracking via Kafka and WebSockets, Redis and Kafka depth all appear at SDE-2
Machine coding is a hard gate at SDE-2; Snake game and food order state machine are the documented patterns
Interviewers penalize hedging explicitly; make decisions and defend them
Senior interviews focus on failure modes, observability, and system evolution

Start with the food delivery architecture. Everything else builds from there.