# SuperStore GenAI Assistant

URL: https://mepritam.dev/work/nykaa-superstore-genai/

An engineering case study: architecting a production GenAI (RAG-style) shopping assistant on LangGraph with custom embedding-based retrieval — no vector database — integrated into Nykaa's high-traffic commerce flows.

---

> A deliberately **sanitised** case study — it covers architecture, constraints,
> and trade-offs, not proprietary data or numbers. For the deeper retrieval
> write-up see the tech note
> [Building a GenAI chatbot without a vector database](/references/building-genai-chatbot-without-vector-database/).

### The problem

SuperStore needed an in-app **shopping assistant** that could answer product and
commerce questions grounded in live catalogue data — at the traffic and latency
profile of a major Indian beauty platform. The hard constraints shaped every
decision: responses had to be **grounded** (no hallucinated products), **fast**
enough for an in-app chat, **cost-bounded** at scale, and **operable** by a small
team.

### Why no vector database

The reflexive answer to "RAG" is a vector DB. For this domain it wasn't the right
trade-off. The catalogue is **structured and bounded** per query context, and
introducing a vector store added operational surface (a service to run, index,
shard, and pay for) that the retrieval quality didn't require. Instead, product
and commerce data is converted into **structured JSON embeddings** and looked up
with a lightweight semantic match. The result: **fewer moving parts, lower latency
on the hot path, and a smaller cost and ops footprint** — the kind of "remove the
component" decision that ages well.

The trade-off is honest: this approach suits a **bounded, structured corpus**, not
an open-ended document store. Naming where a pattern _stops_ applying is part of
the design.

### Architecture

- **Orchestration — LangGraph.** The assistant is a **state machine**, not a
  prompt: explicit nodes for intent, retrieval, tool-calling into commerce flows,
  grounding, and guardrails. State machines make an LLM system **testable and
  debuggable** instead of a black box.
- **Retrieval.** Structured-JSON embedding index over catalogue/commerce data;
  semantic lookup returns grounded context the model must cite.
- **Performance.** **Caching** on common intents and **fallback paths** keep p-tail
  latency and token cost predictable when traffic spikes.
- **Integration.** Wired into Nykaa's existing commerce flows and a **hybrid
  Next.js + Android** surface so the chat bridges web and native in-app journeys.

### Engineering for confidence

LLM features fail quietly, so correctness was treated as a first-class concern: a
**systematic Jest strategy reached 95%+ unit-test coverage** on the SuperStore
front end, and an **evaluation harness** checked grounding and answer quality so
regressions surfaced before release, not in production.

### What I'd revisit at scale

If the corpus grew open-ended or multi-tenant, a managed vector store would start
to earn its complexity — and an offline eval/feedback loop would graduate from
"harness" to a continuous quality pipeline. Knowing _when_ a heavier component
starts paying for itself is the actual design judgement here.