Zomato — Industry problem

Overview

Zomato operates a three-sided marketplace: users discover food, restaurants fulfil orders, and delivery partners bridge the last mile. At scale, the product is less about a single app and more about coordination under uncertainty—traffic, kitchen load, rider availability, and fraud all change by the minute.

Engineering students often study algorithms in isolation; here, latency budgets, partial failures, and business metrics (ETA accuracy, cancellation rate) constrain every design choice.

Technical problems at scale

Search and ranking at local scale

Results must reflect distance, ratings, offers, inventory, and personalization. Inverted indexes and geo-sharding are typical; re-ranking layers apply ML models with strict serving SLAs.

Dispatch and the assignment problem

Which rider picks up which order is a continuous optimization problem—similar to dynamic vehicle routing with soft time windows. Greedy heuristics, batching, and experimentation pipelines back production dispatchers.

Peak traffic and graceful degradation

Friday dinner spikes can overwhelm dependencies. Teams use caching, queueing, feature flags, and read replicas so core flows (place order, track rider) stay up even if recommendations or images load slower.

Payments, refunds, and ledger correctness

Money movement demands idempotency, reconciliation, and audit trails—classic distributed systems concerns (exactly-once semantics, outbox patterns).

Systems & patterns you will hear about

Microservices
Geo-partitioned data
Redis / in-memory caches
Kafka or similar event buses
Maps & routing APIs
Observability (traces, metrics)

Case-study angles

A useful classroom framing: draw the data flow from “user taps Pay” to “restaurant sees order” and list every service that could fail. Then assign retries, timeouts, and fallbacks per hop.

Compare strong consistency (wallet balance) vs eventual consistency (search index)—where would you tolerate lag?