Case studyProduction

ParkBuddy

A production RAG assistant on Google Gemini and MongoDB vector search that autonomously resolves 60–70% of Tier-1 support queries in under 2 seconds — right inside WhatsApp, where customers already are.

Role
Full-Stack & AI Engineer · GoParkEasy
Timeline
Nov 2025 – Present
Links
Visit Proprietary
Node.jsGoogle GeminiMongoDB Vector SearchWhatsApp APIBullMQUpstash Redis
60–70%
Tier-1 queries auto-resolved
<2s
avg resolution time
↓10–20%
database load
24/7
autonomous coverage
01

The problem

GoParkEasy's support inbox was dominated by repetitive Tier-1 questions — pricing, how-to-book, location and timing queries, refund status. The answers already existed in the help material; agents were spending their day retyping them.

That work didn't scale. Response times stretched during peak hours, the load grew with every new user, and skilled agents were stuck on questions a machine could answer — instead of the genuinely hard cases that need a human.

Customers also weren't on a support portal. They were on WhatsApp. Any solution had to meet them there.

02

The approach

A scripted decision-tree bot would be brittle and frustrating; a raw LLM would hallucinate confidently about pricing and policies — the worst possible failure mode for support. So I built a Retrieval-Augmented Generation (RAG) pipeline that grounds every answer in GoParkEasy's actual help corpus.

Incoming questions are embedded and matched against a vector index of the knowledge base; the most relevant passages are retrieved and handed to Gemini as context, which composes a natural, on-brand reply. When confidence is low or the question falls outside scope, the bot escalates to a human instead of guessing.

The whole thing lives on WhatsApp, a multi-tier cache (Upstash Redis + in-memory LRU) keeps hot queries off the database, and anything heavy or non-blocking (ingestion, logging, follow-up jobs) runs off the request path through a BullMQ queue.

03

Architecture

Ingestionoffline
Help docs & FAQs
knowledge base
Chunk + clean
split into passages
Embed
Gemini embeddings
Atlas Vector index
stored vectors
Queryrealtime
Customer
WhatsApp message
WhatsApp webhook
→ Node backend
Cache check
Redis + LRU
Vector search
top-k retrieval
Gemini synthesis
answer + guardrails
Reply
via WhatsApp

// A multi-tier cache (Upstash Redis + in-memory LRU) absorbs hot queries; BullMQ + Redis keep ingestion, logging, and follow-up jobs off the request path, so replies land in under 2s under load.

04

How it's built

  • Chunked the knowledge base into retrieval-friendly passages and embedded them into a MongoDB vector search index — keeping vectors next to the operational data instead of standing up a separate vector DB.
  • On each message: check the cache, embed the query, run top-k vector retrieval, and construct a context-grounded prompt for Gemini with explicit guardrails — answer only from retrieved context, and escalate rather than speculate.
  • Profiled query performance with Python/SQL EDA and added a multi-tier cache (Upstash Redis + in-memory LRU) for hot queries, cutting database load by 10–20% (verified via cache hit ratios and query logs).
  • Integrated the WhatsApp Business API for inbound webhooks and outbound replies, and offloaded ingestion, logging, and follow-up work to a BullMQ pipeline backed by Redis.
05

The outcome

60–70% of Tier-1 queries are now resolved autonomously in under 2 seconds, freeing the support team to focus on the complex cases that actually need them.

The caching layer cut database load by 10–20%, and the system holds up 24/7 — every customer gets the same accurate, on-brand answer, instantly, at any hour.

Because answers are grounded in the live help corpus, the system improves simply by improving the docs — and unresolved questions become a roadmap for what to add next.

Next case study
AI Receptionist
Real-time voice AI receptionist

Want the deep dive?

Happy to walk through the design decisions and trade-offs.