Designing and Scaling Swiggy's Support Chatbot Architecture

1. Introduction: The Hyperlocal Support Problem

Hyperlocal delivery platforms like Swiggy operate under strict SLA constraints and high operational friction. In an environment processing millions of orders daily, issues such as spilled food, late deliveries, missing items, or order cancellations are inevitable.

Handling these edge cases purely through human customer service representatives introduces massive operational expenditure and high customer wait times. A typical phone call or live-agent chat takes anywhere from 5 to 10 minutes to resolve. To achieve business efficiency at scale, Swiggy re-architected its customer resolution pipeline into a self-serve automated chatbot system that reduces resolution times to under 10 seconds while minimizing human agent intervention.

---

2. Core Mental Model: Chatbots as Decision Trees

When designing conversational interfaces for transactional support, teams often jump prematurely to complex Natural Language Processing (NLP) or conversational AI. In production customer support for operations like cancellations or refunds, non-deterministic language models can lead to hallucinated policies, ambiguous commitments, or compliance violations.

Swiggy framed the core chatbot system as a deterministic, stateful Directed Acyclic Graph (DAG) or Decision Tree:

                    [Start Node: Support Intent]
                                 |
       +-------------------------+-------------------------+
       |                         |                         |
[Spilled Item]           [Delayed Delivery]         [Cancel Order]
       |                         |                         |
[Upload Image]           [Check ETA / GPS]          [Check Prep Status]
       |                         |                         |
[Refund / Agent]         [Show Real-time ETA]       [Cancellation Fee]

How the Decision Tree Operates

1. Root Node: The customer triggers support for a specific order.
2. Context-Aware Children: The bot presents valid child nodes based on order state (e.g., if an order is already delivered, cancellation is not a valid child node).
3. State Transition: Selecting an option navigates the customer to the next deterministic node (e.g., verifying order preparation status, calculating cancellation fees, or prompting for proof).
4. Action Execution: Terminal nodes trigger backend workflows (e.g., releasing a refund via the payment service, cancelling the delivery fleet assignment, or routing to a live agent).

Designing the Tree Using Historical Telemetry

The decision tree is not designed on intuition alone; it is derived from historical customer support telemetry. By analyzing the top contact drivers (e.g., top 5 cancellation reasons), product and operations teams curate optimal resolution branches that resolve queries in the minimal number of taps.

---

3. Frontend Strategy: Native App vs. React WebView

One of the most consequential architectural choices was decoupling the chatbot UI from the core native mobile application (iOS/Android).

+-------------------------------------------------------------+
| Swiggy Native Mobile App (iOS / Android)                    |
|  +-------------------------------------------------------+  |
|  | Embedded WebView Container                            |  |
|  |   +-------------------------------------------------+ |  |
|  |   | React Frontend (Served dynamically from CDN)    | |  |
|  |   | - Renders current node & child options          | |  |
|  |   | - Instant updates without App Store reviews     | |  |
|  |   +-------------------------------------------------+ |  |
|  +-------------------------------------------------------+  |
+-------------------------------------------------------------+

Why WebView?

• Rapid Release Cycles: Support flows, business policies, refund limits, and UI copy change frequently. A native implementation requires submitting app updates to the Google Play Store and Apple App Store, subject to review latency and delayed user adoption.
• Zero-Friction Iteration: By rendering a responsive React web application inside a native WebView, front-end changes, A/B tests on decision tree flows, and hotfixes deploy instantly across all mobile clients.
• UI Performance Balance: While heavy graphics require native rendering, support interactions consist of lightweight text and button options where WebView performance overhead is negligible.

---

4. High-Level System Architecture

The support ecosystem spans multiple internal domains, integrating transactional services, event buses, agent tooling, and risk engines.

+----------+
| Customer | <--(WebView / React)---+
+----+-----+
     |
     v
+---------------------------------------------------------------+
|                     Bot Orchestrator                          |
+----+-------------------+---------------------+----------------+
     |                   |                     | 
     v                   v                     v
+-----------+     +--------------+     +------------------------+
| Decision  |     | Notification |     | Fraud Engine           |
| Tree DB   |     | Service      |     | (ML Signal Evaluation) |
+-----------+     +--------------+     +-----------+------------+
                                                   ^
+--------------------------------------------------+------------+
| Core Microservices: Order, Payment, Logistics (via Kafka)     |
+--------------------------------------------------+------------+
                                                   |
                                                   v
                                       +------------------------+
                                       | Agent Workbench        |
                                       | (Human Escalation)     |
                                       +------------------------+

Key Architectural Components

1. Bot Orchestrator: The central controller coordinating user interactions, managing conversation states, traversing the decision tree, and triggering domain actions.
2. Decision Tree Store: Relational and document databases housing the structural definition of nodes, conditions, and business rules configured by product and operational managers.
3. Agent Workbench: A dedicated interface for human support personnel. If a user escalates out of the decision tree, the session transfers to a live agent. Crucially, the entire state history and previous selections are synced so the customer never repeats context.
4. Domain Services Integration:
   • Order Service: Checks real-time kitchen status, prep progress, and order contents.
   • Logistics Service: Fetches rider GPS telemetry, predicted delivery times, and route blockers.
   • Payment & Refund Service: Triggers instantaneous reversals or platform credits upon automated approval.
   • Notification Service: Dispatches transactional SMS, WhatsApp, and push updates asynchronously.

---

5. Fraud Detection and Risk Modeling

Self-service refund workflows introduce an immediate vector for exploitation, including false claims of non-delivery, damaged food, or missing items.

To prevent abuse without penalizing honest customers, the chatbot orchestrator evaluates risk inline before terminal actions execute:

• Signal Ingestion: As the user navigates the tree, the Fraud Modeling Engine ingests real-time signals along with historical features via event streams.
  • Customer refund-to-order ratio.
  • Historical abuse scores.
  • Order-specific anomalies (e.g., driver GPS indicates successful delivery within 10 meters of the doorstep).
  • Payment profile risk signals.
• Inline Risk Segmentation:
  • Low-Risk Segment: The bot grants instant refunds or credits automatically.
  • High-Risk Segment: The bot disables instant refund branches, mandates photographic proof, or reroutes the user to a specialized human agent for manual verification.

---

6. Business Continuity Planning (BCP)

Support infrastructure cannot go down. If peak-load meal rushes cause database degradation or internal service failures in the automated bot, customers must not be locked out of resolving critical order issues.

• Third-Party Agent Fallback: Swiggy provisions an isolated, third-party live-chat fallback provider.
• Failover Trigger: If the primary Bot Orchestrator experiences high error rates, elevated latency, or network partition from core services, the gateway switches traffic to the third-party chat platform.
• While agent wait times increase during fallback, availability remains intact, preserving customer trust.

---

7. The North Star Metric: Bot Efficacy Percentage

The architectural and operational performance of this system is governed by a primary business-critical metric:

$\text{Bot Efficacy (\%)} = \left( \frac{\text{Conversations Resolved Completely by Bot}}{\text{Total Customer Support Invocations}} \right) \times 100$

Every percentage point increase directly correlates to reduced operational burn on human agents and lower customer resolution latency. By continuously mining unhandled customer exit points and extending the decision tree, engineering and operations iteratively boost this efficacy score.

---

8. Technology Stack Breakdown

Component Layer	Technologies Used	Architectural Role
Frontend	React (in Mobile WebView)	Dynamic UI rendering, rapid deployment without App Store reviews.
Backend Services	Java, Node.js, Ruby on Rails	Core microservices handling orders, authentication, and orchestrations.
Event Backbone	Apache Kafka	Asynchronous messaging, telemetry streaming to fraud engine and analytics.
State & Persistence	MySQL, PostgreSQL	Relational storage for decision tree structures, order records, and user state.
Caching Layer	Redis	Fast session lookup, active conversation state caching, and rate limiting.

---

9. Architectural Takeaways

1. Pragmatism Over Hype: Deterministic decision trees with explicit state management often provide far higher reliability, auditability, and speed than conversational AI/NLP in transactional workflows.
2. Decouple Fast-Moving UI via WebViews: For internal workflows and support operations requiring frequent iterations, embedding web views saves months of native app release cycles.
3. Inline Risk Controls are Non-Negotiable: Fully automated self-service financial workflows (like refunds) must be coupled with real-time fraud scoring engines.
4. Always Architect for Degraded Fallbacks: Support systems require automated BCP cutovers to ensure high availability even when internal services fail.