QuickCart — User Flow

Core journey stages

1 tap

To compare 5 sources

<1.5s

To first ranked results

QuickCart collapses "check five apps" into one action. Everything below is written from the shopper's point of view first, then unpacked into the system behaviour that makes each step fast and reliable.

The end-to-end journey

A shopper opens the app, finds a product by browsing or searching, sees the best offer across all connected platforms, and either checks out in-app or is handed off to the source app. If nothing matches, the query is captured so the catalogue can grow — the shopper never hits a dead end.

flowchart TD A(["Launch app"]) --> B{"First run?"} B -- "Yes" --> ONB["Onboarding
+ location permission"] B -- "No" --> HOME["Home screen"] ONB --> HOME HOME --> ACT{"Browse or search?"} ACT -- "Browse" --> CAT["Category / list screen"] ACT -- "Search" --> SR["Enter query"] CAT --> SR SR --> RES["Aggregated results
best price · stock · ETA"] RES --> DET["Product detail
5-source compare"] DET --> M{"Found a match?"} M -- "No match" --> MISS["Missing-SKU loop"] M -- "Yes" --> ADD["Add to cart"] ADD --> CART["Cart / review"] CART --> CO["Checkout + payment"] CO --> H{"Fulfilment mode?"} H -- "In-app" --> PLACED["Order placed
in QuickCart"] H -- "Deep-link" --> HAND["Handoff to
source app"] PLACED --> TRK["Live order tracking"] HAND --> TRK TRK --> DEL(["Delivered"]) DEL --> RATE["Rate & reorder"] RATE --> HOME MISS -. "notify when added" .-> HOME

Figure 2.1 — The complete shopper journey. The "no match" branch feeds the missing-SKU loop (Figure 2.3) rather than dead-ending.

Search request lifecycle

Behind a single search, the API gateway checks a short-lived cache and, on a miss, fans out to all five platform MCPs in parallel. Results are normalised, matched to canonical SKUs and ranked before returning. A hard deadline guarantees the shopper sees something even if one source is slow.

sequenceDiagram autonumber actor Shopper participant App as Mobile App participant GW as API Gateway participant AGG as Aggregation Svc participant MCP as Platform MCPs participant Cache as Redis Cache Shopper->>App: Type search query App->>GW: GET /search?q=...&lat&lng GW->>Cache: Lookup cached offers Cache-->>GW: Miss GW->>AGG: Dispatch aggregation par Blinkit AGG->>MCP: search(query) and Zepto AGG->>MCP: search(query) and BigBasket AGG->>MCP: search(query) and Flipkart AGG->>MCP: search(query) and Amazon AGG->>MCP: search(query) end MCP-->>AGG: Raw offers per platform Note over AGG: Deadline 1.2s — return partial
results if a source is slow AGG->>AGG: Normalise + SKU-match + rank AGG->>Cache: Store ranked offers (TTL 60s) AGG-->>GW: Ranked offers[] GW-->>App: 200 offers[] App-->>Shopper: Render best price / stock / ETA

Figure 2.2 — Search request lifecycle. Scatter-gather to five MCPs with a 1.2s deadline; see Document 05 for the ranking algorithm.

Partial results are a feature, not an error If a source misses the 1.2s deadline it is dropped from this response and refreshed asynchronously. The UI labels the offer set "showing 4 of 5 sources" rather than blocking on the slowest platform.

Missing-SKU capture loop

When a search returns nothing (or only weak matches), the query is never thrown away. It enters a queue that clusters similar misses, enriches them from platform browse endpoints and external product data, and either auto-creates a canonical catalogue entry or routes it to human review. The full data model lives in Document 03 — Missing-SKU Discovery.

flowchart LR Q["Search with
no / low match"] --> LOG[("Missing-SKU
queue")] LOG --> DED["Dedupe & cluster
similar queries"] DED --> ENR["Enrich:
MCP browse +
external product data"] ENR --> AUTO{"Auto-match
confidence?"} AUTO -- "High" --> ENT["Create canonical
catalogue entry"] AUTO -- "Low" --> REV["Human review
queue"] REV --> ENT ENT --> SRCH["Becomes
searchable"] SRCH --> NOTE["Shopper notified
/ auto-retried"]

Figure 2.3 — Missing-SKU capture loop. Demand signal (real searches) drives catalogue growth; low-confidence matches get a human in the loop.

Order lifecycle

Once a shopper checks out, the order moves through a well-defined state machine owned by the Order service, with payment and refunds coordinated by the Payment service. Every transition emits an analytics event (see Document 03 — Analytics).

stateDiagram-v2 [*] --> CREATED CREATED --> PAYMENT_PENDING: checkout PAYMENT_PENDING --> PAID: payment authorised PAYMENT_PENDING --> PAYMENT_FAILED: declined / timeout PAYMENT_FAILED --> PAYMENT_PENDING: retry PAYMENT_FAILED --> CANCELLED: give up PAID --> PLACED_WITH_SOURCE: forward to platform PLACED_WITH_SOURCE --> PICKING PICKING --> OUT_FOR_DELIVERY OUT_FOR_DELIVERY --> DELIVERED DELIVERED --> [*] PAID --> CANCELLED: cancel before pick CANCELLED --> REFUNDED: refund issued REFUNDED --> [*]

Figure 2.4 — Order state machine. PAYMENT_FAILED is recoverable; a cancellation after payment always routes through REFUNDED.

Who owns each stage

Journey stage → backend service Search / compare → Aggregation service + Catalogue service (Doc 05, Doc 03) · Source data & live stock → Platform MCP adaptors (Doc 04) · Cart / order state → Order service (Doc 03) · Payment / refund → Payment service (Doc 03) · No-match → Missing-SKU pipeline (Doc 03).

Edge cases we handle

The happy path is easy; the value is in the failure paths. Each of these has an explicit branch in the flows above.

No results

Nothing matched

Show related suggestions, log the query to the missing-SKU queue, and offer "notify me when available."

Partial outage

A source is down or slow

Drop the source past the 1.2s deadline, badge results "4 of 5 sources," and backfill on the next refresh.

Stale offer

Price or stock changed at checkout

Re-validate the winning offer before payment; if it moved, show a one-tap "accept new price" or re-rank.

Coverage

Address outside all delivery zones

Detect at location step; fall back to standard-delivery sources (Amazon/Flipkart) or waitlist the pincode.

Payment

Payment failure & retry

Keep the cart, hold the order in PAYMENT_PENDING, allow a different method, and auto-expire after N minutes.

Ambiguity

Duplicate / ambiguous match

When two SKUs match the query closely, present a disambiguation card instead of guessing the wrong pack size.