How Swiggy Closed the Gap Between an Order and the Shelf

By the time Swiggy brought us into the Microsoft Fabric build, the operating problem on Instamart wasn't the data — it was the lag. Swiggy is one of India's largest on-demand convenience platforms: 23 million monthly transacting users, 3 to 4 million orders a day across food and quick-commerce, 690,000 delivery riders, 260,000 restaurant partners, and 1,100+ "dark stores" across more than 700 cities. The legacy operational pipeline took up to ten minutes to refresh dashboards. In a business where Instamart promises a ten-minute window and food orders land in thirty, a ten-minute reporting lag is the entire delivery window. If sanitary pads ran out at a particular dark store, it took five to ten minutes for that fact to surface in the app — long enough for frustrated customers to place orders the store couldn't fulfil, and long enough for store managers to be the last to know.

The new operational data platform runs end-to-end on Microsoft Fabric, with Real-Time Intelligence (RTI) as the streaming surface and Azure OpenAI Service powering the customer- and rider-facing chat layer. Order telemetry, inventory events from the dark stores, rider GPS pings, and restaurant-partner status all land in Fabric's OneLake through the streaming path; RTI processes the event stream and projects it into the dashboards and downstream consumers that actually drive the operation. The shape of the platform is deliberately unbatched: an event happens at a dark store, in a rider's app, or on a customer's order, and that event reaches the operational surface in seconds rather than minutes. On top of the real-time surface, three Gen-AI applications wrap the platform for end users. The customer-facing chatbot answers "where is my order?" against the same live event stream — no extra contact-centre staff during peak windows. "Driver Dost", the rider-facing assistant, handles onboarding, earnings, and route guidance, with Azure OpenAI tuned for the conversational register Indian delivery riders actually use. A third assistant, planned for restaurant partners, will sit on the same RTI backbone. Crucially, the rebuild gave Swiggy operational primitives the legacy stack could not. Dynamic rider routing now reads incoming order density in near-real-time and steers riders toward neighbourhoods where volume is spiking — useful when rain chokes a road and the demand curve shifts within minutes. RTI also detects unusual spikes in coupon usage that indicate leaked discount codes, and lets Swiggy discontinue the coupon before the loss compounds. The same fabric of events powers the customer assistant, the rider assistant, and the fraud-detection loop — one surface, three consumers.

Two things, honestly. First, we under-invested in the dark-store event schema upfront. Each store sends inventory events slightly differently depending on the local POS configuration, and the first three weeks of streaming traffic forced us to normalise schemas in flight rather than at the edge. A schema-validation layer at the store gateway, written as a first-class component before any RTI traffic, would have shortened the stabilisation window. Second, we shipped the customer assistant against a Gen-AI-shaped intent taxonomy before we had enough live "where is my order?" traffic to confirm the actual intent distribution. The taxonomy held, but two of the buckets were over-fitted to assumed intents that didn't appear at volume. Next deployment, the assistant ships after two weeks of read-only logging against the live channel, not before.