DEV Community

Cover image for Building a Zero-Waste RAG Pipeline with Qwen Cloud
Andrew Irorere
Andrew Irorere

Posted on

Building a Zero-Waste RAG Pipeline with Qwen Cloud

#ai #webdev #rag #nextjs

When building NameFinder, a linguistic platform designed to uncover the etymology and origin data of names, the biggest architectural hurdle wasn't the database or the UI layout. It was protecting the API budget.

Standard Retrieval-Augmented Generation (RAG) pipelines are notoriously big token spenders. If your application invokes a Large Language Model to generate a response every single time a user hits the search bar, you will run through your API quota and hit rate limits very quickly.

To scale Namefinder for a global audience, I built a loop-free, "zero-waste" hybrid caching pipeline using Qwen Cloud and Supabase. This architecture ensures we pay for LLM generation only when necessary, delivering instant results to users while keeping infrastructure costs near zero.

The Zero-Waste Architecture: Fetch-and-Check Caching

The optimised architecture relies on a strict "Fetch-and-Check" sequence that treats the LLM as an emergency worker rather than a full-time factory hand.

Here is exactly how the pipeline processes a search step-by-step:

Step 1: User Query and Embedding Generation

When a user searches for a name or meaning on the Frontend Next.js website, the query is passed to the Backend (Next.js API). The backend takes the query string and sends it to Qwen Cloud’s text-embedding-v2 model. This converts the text into a mathematical vector representation.

To keep the codebase modular, this client initialisation lives in a dedicated utility file (lib/qwenclient.ts) and points cleanly to the DashScope-compatible endpoint:

TypeScript

// lib/qwenclient.ts
import OpenAI from 'openai';

export const qwenClient = new OpenAI({
  apiKey: process.env.QWEN_API_KEY,
  baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
});
Enter fullscreen mode Exit fullscreen mode

Step 2: Query Supabase First

Instead of passing the embedding directly to a generative prompt, the backend performs a vector similarity search in the Database (Supabase PostgreSQL + pgvector). It looks for rows in the database where the semantic meaning closely matches the user's intent.

If the database returns a matching row with the name, the application checks if the critical data columns—like linguistic_root, etymology, and region_origin—are fully populated. If the data is there, the backend intercepts the flow, completely bypasses the LLM, and serves the cached data to the frontend layout instantly. Cost: 0 generation tokens.

Step 3: Targeted LLM Enrichment (The Fallback)

If the database match comes up empty, or if the etymology columns contain missing or incomplete records, the system triggers the generative fallback.

The backend calls the Qwen Cloud API (LLM) using a highly structured system prompt. The model is instructed to output a strict JSON object containing only the missing historical data, linguistic roots, and structural segments required to render the application's dynamic details.

Step 4: Permanent Caching

The moment Qwen Cloud returns the generated JSON object, the backend performs two concurrent tasks:

  1. It returns the full name info straight back to the frontend UI so the layout populates seamlessly.

  2. It pushes the new data downstream to cache the generated data back into the Supabase database.

Because this database write is coupled directly to the successful resolution of the API handler, it runs exactly once per unique missing query. This avoids complex frontend state loops and guarantees that the next user searching for that name will get an instant database read, completely free of charge.

Why This Matters for Production

By treating the LLM as a data-enrichment tool rather than a persistent runtime engine, this pipeline achieves three major milestones:

  • Drastic Cost Reductions: As the user base grows and the database fills up, the reliance on the generative API decreases exponentially.

  • Sub-Second Latency: Database reads take milliseconds, whereas generating fresh LLM responses can take seconds. Serving cached data dramatically improves the global user experience, especially on mobile networks.

  • Resiliency: If an AI service hits a rate limit or goes down mid-competition, the platform doesn't crash; it gracefully continues to serve existing historical data straight from the local PostgreSQL instance.

Building with modern tooling like Next.js, Supabase, and Qwen Cloud makes it highly practical to achieve top-tier performance without sacrificing technical depth or breaking the development budget.

Top comments (0)