How Swiggy Built a Logistics Network in Cities Where No Addresses Existed

The Logistics Problem Nobody Talks About Behind Swiggy's Growth

Everyone knows Swiggy as a food delivery app. Few people understand the actual engineering and operational problem they had to solve before a single order could be delivered.

In India, addresses do not work the way software assumes they do. There is no standardised postcode system that maps cleanly to a physical location. Lanes do not have names. Buildings do not have numbers. Landmarks change. And in dense urban neighbourhoods — the exact places with the highest concentration of hungry customers — GPS coordinates drop you within 50 metres of a destination that could be behind a wall, inside a gated colony, or accessible only through an alley that does not appear on any map.

Swiggy had to solve this before they could deliver anything. This is the story of how they did it.

🎯 Quick Answer (30-Second Read)

• The core problem: Indian addresses are unstructured, landmark-based, and unmappable by conventional GPS
• What Swiggy built: A proprietary geospatial layer on top of Google Maps using delivery partner movement data
• The key insight: Delivery partners' GPS traces are more accurate than any map database for last-mile navigation
• How it scales: Every completed delivery improves the address graph for the next delivery to the same area
• The operational layer: Hyperlocal delivery zones, dark stores, and fleet optimisation that runs on real-time demand signals
• Why competitors struggled: The address graph is a data moat — you can copy the app but you cannot copy three years of delivery traces

Why Indian Addresses Break Every Assumption in Logistics Software

Standard logistics software is built on a foundational assumption: addresses are structured, unique, and geocodable. You enter a street, a building number, a postcode — the system converts it to a latitude and longitude and routes accordingly.

This assumption fails in most of India.

A real delivery address in a tier-one Indian city might look like this:

Opposite the blue water tank, third lane after the petrol pump,
near Rajesh Medical Store, ground floor, green gate

There is no street name. There is no building number. The landmarks are informal, local, and change over time. The petrol pump might close. Rajesh Medical Store might relocate. The blue water tank might be repainted.

Google Maps — built primarily on structured Western address data — does not know what to do with this. It can get a delivery partner to the neighbourhood. It cannot get them to the door.

This is not a small problem. This is the entire last-mile problem for food delivery in India. And last-mile is where the cost, the time, and the customer experience are determined.

What Swiggy Actually Built

Swiggy built three interlocking systems that together solved what Google Maps alone could not.

1. The Proprietary Address Graph

Every delivery generates a GPS trace — the path a delivery partner took from the restaurant to the customer's door. Swiggy collects these traces and uses them to build a proprietary address graph that maps informal, landmark-based addresses to precise delivery coordinates.

The first delivery to a new address is imprecise. The tenth delivery to the same building is accurate to within a few metres. The hundredth delivery to that neighbourhood produces a dense trace network that allows Swiggy's routing system to navigate lanes and alleys that do not exist on any commercial map.

This is a data flywheel. Every delivery improves the address graph. A better address graph enables faster, more accurate deliveries. Faster deliveries enable more orders. More orders generate more traces. The accuracy compounds.

2. Hyperlocal Zone Architecture

Swiggy divided cities not by administrative boundaries but by delivery feasibility. Each zone is sized so that any restaurant within it can reach any customer within it within a target delivery time — originally 45 minutes, later compressed to 30 minutes for Swiggy Instamart.

Zone boundaries are not fixed. They adjust dynamically based on traffic conditions, fleet availability, weather, and demand patterns. A zone might expand during low-traffic periods when delivery partners can cover more ground, and contract during rush hour when the same distance takes twice as long.

This hyperlocal architecture means Swiggy is not operating one logistics network across a city. They are operating hundreds of overlapping micro-networks, each optimised for its own conditions.

3. Real-Time Fleet Optimisation

Assigning the right delivery partner to the right order at the right moment is an optimisation problem that runs millions of times per day. Swiggy's dispatch system considers partner location, current load, historical performance on similar routes, restaurant preparation time, and predicted traffic — all in real time.

The system does not just optimise individual assignments. It pre-positions fleet before demand spikes. If historical data shows that orders in a particular neighbourhood spike at 12:30pm on weekdays, the system encourages delivery partners to be in that area at 12:15pm through incentive signals — surge pricing, guaranteed earnings, or simply routing them there during idle periods.

The Dark Store Bet That Changed Everything

Swiggy Instamart — the 10-minute grocery delivery product — required a fundamentally different infrastructure bet: dark stores.

A dark store is a small warehouse, typically 2,000–4,000 square feet, positioned inside a residential neighbourhood. It stocks the 2,000–5,000 SKUs that account for the majority of grocery orders in that catchment area. It has no retail frontage. Customers never visit. It exists entirely to serve delivery orders.

The dark store model solved the last-mile problem from the supply side. Instead of routing a delivery partner from a distant warehouse through city traffic to a customer, the dark store puts inventory within 1–2 kilometres of the customer before the order is even placed.

At that distance, a 10-minute delivery is physically achievable. Without it, it is not.

The site selection for dark stores is itself a data problem. Swiggy uses order density maps, demographic data, and real estate availability to identify the precise locations where a dark store will serve the maximum number of customers within the target radius. A poorly placed dark store is expensive dead weight. A well-placed one serves tens of thousands of orders per month from a single location.

My Take — What Swiggy Actually Solved That Nobody Gives Them Credit For

I think about infrastructure problems at this level a lot — the kind where the constraint is not technology but reality. The ground truth of a country that was never built for the assumptions your software makes.

What Swiggy solved is genuinely hard. Not hard like a complex algorithm. Hard like — the map is wrong, the addresses don't exist, the roads don't have names, and you still have to get hot food there in 30 minutes. That is a different category of problem.

The part that impresses me most is not the app. It is the address graph. They built a mapping layer for India that Google had not built — not because Google lacked the resources, but because Google's incentive was global scale and Swiggy's incentive was last-mile accuracy in Koramangala. Those are different problems with different solutions.

The worst version of this problem is what Zomato and every other competitor faced when they tried to replicate Swiggy's delivery speed — you can copy the interface, you can copy the pricing, you can copy the dark store model. You cannot copy three years of GPS traces. That data moat is the actual business.

The future is interesting here — as India's addressing infrastructure improves (the government's digital address programme is a real initiative), the value of Swiggy's proprietary address graph will either compound further or be commoditised. If official addresses become reliable, the moat narrows. If they remain incomplete — which is likely for at least a decade — Swiggy's trace data stays the most accurate ground truth available. I think the trace data stays valuable longer than people expect, because official addresses being created does not mean they get adopted by the people who currently navigate by landmark.

The better way to think about what Swiggy built is not a delivery company. It is a data company that delivers food. The delivery generates the data. The data enables the delivery. That loop is the real product.

How the Logistics Stack Compares to Western Counterparts

The contrast is stark. DoorDash and Deliveroo operate on top of reliable address infrastructure. Their logistics problem is fleet management and route optimisation — hard, but well-understood. Swiggy had to solve address resolution before they could even begin the logistics problem that their Western counterparts started with.

The Engineering Decisions That Made It Scale

Polyglot persistence. Swiggy's platform uses different databases for different problems — MySQL for transactional order data, Elasticsearch for restaurant and menu search, Redis for real-time session and cart data, and a custom geospatial store for the address graph. Each data type lives in the system optimised for its access pattern.

Event-driven architecture. Order state changes — placed, confirmed, picked up, delivered — emit events that multiple downstream systems consume independently. The notification system, the analytics pipeline, the inventory system, and the fleet optimisation system all react to the same events without coupling to each other.

Graceful degradation under load. During peak periods — Sunday evenings, IPL match nights, monsoon days — Swiggy's systems shed non-critical features to protect core order flow. Search ranking personalisation might be disabled. Real-time restaurant ratings might serve cached data. But order placement, payment, and dispatch continue at full fidelity.

Real World Impact: The Numbers Behind the Network

Swiggy operates across 500+ Indian cities. The density of their address graph varies enormously — Bangalore and Mumbai have millions of resolved delivery coordinates; a tier-three city added six months ago has a sparse graph still being populated by early deliveries.

This creates a tiered accuracy system. In mature markets, Swiggy's delivery time estimates are accurate to within two or three minutes because the routing system has precise coordinates and dense historical traffic data. In newer markets, estimates are wider and delivery partners rely more on phone calls to customers for final navigation.

The improvement curve is steep. A new city goes from sparse to reasonably accurate within six to nine months of meaningful order volume. The address graph self-corrects — a wrong coordinate gets flagged by delivery partners and updated, gradually converging on ground truth.

Frequently Asked Questions

How does Swiggy handle addresses that genuinely do not exist on any map?
Swiggy uses a combination of customer-provided GPS pin drops, delivery partner real-time location during delivery, and post-delivery confirmation to resolve and store the actual delivery coordinate. The first delivery is navigated partly by phone call between partner and customer. The resulting GPS trace is stored and used for every subsequent delivery to that location — converting a one-time navigation challenge into a cached, reusable coordinate.

Why could Google Maps not just solve this for Swiggy?
Google Maps is optimised for global scale and structured address systems. Its India coverage has improved significantly but still lacks the hyperlocal accuracy needed for last-mile food delivery. More importantly, even accurate GPS coordinates do not solve the problem of which entrance to use, which floor, which gate — information that Swiggy's trace data captures and Google's has no mechanism to collect at delivery-level granularity.

What is a dark store and how does it enable 10-minute delivery?
A dark store is a small fulfilment warehouse positioned inside a residential neighbourhood, stocking the most commonly ordered items in that catchment area. By placing inventory within 1–2 kilometres of the customer before the order is placed, the physical distance a delivery partner must travel is small enough to complete in 10 minutes on a bike. Without dark stores, 10-minute delivery is geometrically impossible regardless of how fast the software is.

How does Swiggy's address graph compare to what competitors have?
Competitors who entered the Indian market later — or who relied entirely on commercial map data — do not have equivalent address graphs. The graph is built from delivery traces, which means it can only be built by completing deliveries. There is no shortcut. A competitor starting today would need years of delivery volume to accumulate comparable accuracy in mature urban markets. This is the data moat that makes Swiggy's logistics position difficult to replicate quickly.

What happens to Swiggy's advantage as India's addressing infrastructure improves?
India's government has initiated a digital address programme aimed at creating structured, geocodable addresses for the entire country. If successful, this would reduce the value of Swiggy's proprietary address graph in urban areas. However, official address adoption historically lags address creation by years — people continue navigating by landmark long after formal addresses exist. The trace data is likely to remain the most accurate ground truth for last-mile delivery in India for the foreseeable future.

Conclusion

Swiggy did not just build a food delivery app. They built a logistics infrastructure layer for a country where the foundational assumption of logistics software — that addresses exist and are geocodable — was false.

The address graph, the hyperlocal zone architecture, the dark store network, and the real-time fleet optimisation are not product features. They are the product. The app is just the interface.

The deepest lesson from Swiggy's logistics story is this: when the infrastructure your software depends on does not exist, you have two choices — wait for it to be built, or build it yourself. Swiggy built it. And in building it, they created a data moat that is harder to overcome than any feature advantage a competitor could ship.

Related reads: How SaaS Companies Actually Make Money · Why Apps Crash During High Traffic · How Anthropic's Safety-First Approach Became Its Strongest Growth Strategy · How OpenAI Turned an API Into the World's Fastest-Growing Developer Ecosystem