DEV Community: Madhu Dadi

Understanding the Production RAG Stack: Streaming and Citations in a Production AI Platform

Madhu Dadi — Tue, 19 May 2026 12:11:17 +0000

Streaming, Citations & Fallbacks: The Production RAG Stack

Production RAG (Retrieval-Augmented Generation) streaming works by sending Server-Sent Events (SSE) from a FastAPI backend to a React frontend via the fetch() ReadableStream API. The first SSE event delivers the user's remaining daily quota, the second shows source citations as clickable badges, and subsequent events stream answer tokens in real time. When connections drop, the frontend retries with exponential backoff. Daily quotas are enforced via Redis atomic counters.

This is part of my full series on building a production AI blog platform: https://madhudadi.in/blog/series/building-this-blog

In the previous post, I covered the core RAG pipeline — chunking, embedding, semantic search, the planner, and multi-provider failover. That's the engine.

This post is the chassis: the streaming wire protocol, the frontend that renders answers token-by-token, the citation badges that link back to source posts, the rate limiting that prevents API bill shock, the reconnection logic that survives network drops, and the chat sessions that give every query a home.

These are the parts that turn a working prototype into something people actually enjoy using. I built every line myself, and it's running in production at madhudadi.in/ask — you can test it right now.

Try the live result →

How SSE Streaming Works in FastAPI: `fetch()` + ReadableStream

The router at POST /api/v1/rag/query returns a StreamingResponse:

@router.post(&quot;/query&quot;)
async def rag_query(
    payload: RagQueryRequest,
    request: Request,
    db: AsyncSession = Depends(get_db),
    current_user: User | None = Depends(get_current_user_optional),
):
    ip = extract_client_ip(request)
    return StreamingResponse(
        _sse_stream(payload, db, current_user, ip),
        media_type=&quot;text/event-stream&quot;,
        headers={
            &quot;X-Accel-Buffering&quot;: &quot;no&quot;,
            &quot;Cache-Control&quot;: &quot;no-cache&quot;,
        },
    )

The X-Accel-Buffering: no header is critical — without it, Nginx (which sits in front of the Docker containers) would buffer the entire response and defeat streaming.

What the SSE Event Sequence Looks Like

Six event types, always in the same order:

data: {&quot;type&quot;: &quot;rate_limit&quot;, &quot;used&quot;: 1, &quot;limit&quot;: 20, &quot;remaining&quot;: 19, &quot;resets_in_seconds&quot;: 36000}

data: {&quot;type&quot;: &quot;planning&quot;, &quot;message&quot;: &quot;Analysing...&quot;}

data: {&quot;type&quot;: &quot;planning&quot;, &quot;message&quot;: &quot;Searching...&quot;}

data: {&quot;type&quot;: &quot;sources&quot;, &quot;posts&quot;: [
  {&quot;title&quot;: &quot;Building a Monorepo that Runs 29 Services&quot;, &quot;slug&quot;: &quot;the-monorepo-that-runs-29-services&quot;},
  {&quot;title&quot;: &quot;Why I Built Yet Another Blog&quot;, &quot;slug&quot;: &quot;why-i-built-yet-another-blog-but-not-really&quot;}
]}

data: {&quot;type&quot;: &quot;token&quot;, &quot;content&quot;: &quot;The monorepo is structured as a FastAPI backend&quot;}

data: {&quot;type&quot;: &quot;token&quot;, &quot;content&quot;: &quot; with separate router modules for each&quot;}

data: {&quot;type&quot;: &quot;token&quot;, &quot;content&quot;: &quot; logical domain...&quot;}

data: {&quot;type&quot;: &quot;done&quot;, &quot;latency_ms&quot;: 2340, &quot;session_id&quot;: &quot;abc-123&quot;}

Event	When	Purpose
`rate_limit`	First event	Shows remaining quota before any computation
`planning`	During planner	Two messages: "Analysing…" then "Searching…"
`sources`	Before generation	Source post titles + slugs for citation badges
`token`	During generation	One per LLM output token
`done`	Completion	Final latency + session_id for continuation
`error`	Any failure	Graceful error message

Why the Frontend Uses `fetch()` Instead of `EventSource`

Standard EventSource can't send POST bodies or Authorization headers. The frontend uses fetch() with a ReadableStream reader:

// src/lib/api/rag.ts — the SSE wire protocol
const reader = res.body!.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  const chunk = decoder.decode(value, { stream: true });
  const lines = chunk.split(&quot;\n&quot;);

  for (const line of lines) {
    if (!line.trim()) continue;
    if (line.startsWith(&quot;data: &quot;)) {
      const data = JSON.parse(line.slice(6));
      onEvent(data);
    }
  }
}

This gives us full control over aborting, retrying, and authentication — none of which EventSource supports.

How the Frontend Dispatches Events

Each data: line is dispatched to a typed callback handler:

switch (event.type) {
  case &quot;rate_limit&quot;:
    // Update quota display immediately
    break;
  case &quot;planning&quot;:
    last.status = &quot;planning&quot;;
    break;
  case &quot;token&quot;:
    last.status = &quot;generating&quot;;
    last.content += event.content;
    break;
  case &quot;sources&quot;:
    last.citations = event.posts.map(p =&gt; ({
      source: p.title, slug: p.slug
    }));
    break;
  case &quot;done&quot;:
    last.status = &quot;done&quot;;
    last.latency = event.latency_ms;
    break;
  case &quot;error&quot;:
    last.status = &quot;error&quot;;
    last.content = event.message;
    break;
}

How Citation Badges Work: Before the First Token

The most user-visible design choice: source badges render before the first token of the answer.

When the sources event arrives (immediately after the planner finishes), the frontend renders clickable badges beneath the answer area:

{msg.citations.length &gt; 0 &amp;&amp; msg.status === &quot;done&quot; &amp;&amp; (
  &lt;div className=&quot;mt-4 pt-3 border-t border-white/[0.06]&quot;&gt;
    &lt;p className=&quot;text-xs text-[var(--text-subtle)] mb-2 font-medium uppercase tracking-wider&quot;&gt;
      Sources
    &lt;/p&gt;
    &lt;div className=&quot;flex flex-wrap gap-2&quot;&gt;
      {dedupedCitations.map((c) =&gt; (
        &lt;Link
          key={c.slug}
          href={`/posts/${c.slug}`}
          className=&quot;inline-flex items-center gap-1.5 text-xs text-amber-400/70
                     hover:text-amber-400 glass px-2.5 py-1 rounded-lg
                     border border-amber-500/15 hover:border-amber-500/30
                     transition-all&quot;
        &gt;
          &lt;BookOpen size={10} /&gt;
          {c.source}
          &lt;ExternalLink size={9} className=&quot;opacity-60&quot; /&gt;
        &lt;/Link&gt;
      ))}
    &lt;/div&gt;
  &lt;/div&gt;
)}

Key implementation details:

Deduplication: If two chunks come from the same post, the badge appears only once (using new Map(citations.map(c => [c.slug, c])))
Links to the actual post: Each badge links to /posts/{slug}
Visual hierarchy: Amber border + glass effect + hover highlight
Timing: Badges appear during generation, not after — builds trust immediately

The actual LLM response does NOT contain inline citation markers like [1]. The system prompt instructs the model to write naturally, and the source badges provide attribution independently.

How the Frontend Handles Network Drops: Exponential Backoff

ARCH-004: up to 3 retries with delays of 1s, 2s, and 4s.

const MAX_RETRIES = 3;
const RETRY_DELAY_MS = 1000;

for (let attempt = 0; attempt &lt;= MAX_RETRIES; attempt++) {
  const controller = new AbortController();
  abortRef.current = controller;

  try {
    await ragApi.query({ query }, onEvent, controller.signal);
    lastError = null;
    break; // Success
  } catch (err) {
    lastError = err;
    if (err instanceof AbortError) break; // User cancelled

    if (attempt &lt; MAX_RETRIES) {
      const delay = RETRY_DELAY_MS * Math.pow(2, attempt);
      // Show &quot;reconnecting...&quot; while waiting
      await waitWithAbort(delay, controller.signal);
    }
  }
}

During retry, the UI shows a "Connection lost — reconnecting…" status:

{msg.status === &quot;reconnecting&quot; &amp;&amp; (
  &lt;StatusPill
    icon={&lt;RefreshCw size={11} className=&quot;animate-spin&quot; /&gt;}
    label=&quot;Connection lost — reconnecting…&quot;
  /&gt;
)}

The retry rate is 0.8% — about 1 in 125 queries experiences a network interruption. Without exponential backoff, those users would see an error.

How Status Indicators Keep Users Informed

While the backend processes the query, the frontend shows four distinct progress states:

State	Icon	What It Tells the User
`planning`	`Brain`	"Analyzing query…" — the planner is rewriting the query
`searching`	`Search`	"Searching knowledge base…" — embedding + vector search
`generating`	pulsing `▌` cursor	Tokens are streaming in real time
`reconnecting`	spinning `RefreshCw`	Network dropped, retrying with backoff

function StatusPill({ icon, label }) {
  return (
    &lt;div className=&quot;flex items-center gap-1.5 text-xs text-[var(--text-muted)] mb-3&quot;&gt;
      &lt;span className=&quot;text-amber-400/60 animate-pulse&quot;&gt;{icon}&lt;/span&gt;
      &lt;span&gt;{label}&lt;/span&gt;
      &lt;span className=&quot;flex gap-0.5 ml-1&quot;&gt;
        {[0, 1, 2].map((i) =&gt; (
          &lt;span key={i} className=&quot;w-1 h-1 rounded-full bg-amber-400/40 animate-bounce&quot;
                style={{ animationDelay: `${i * 0.15}s` }} /&gt;
        ))}
      &lt;/span&gt;
    &lt;/div&gt;
  );
}

The bouncing dots animation provides micro-feedback during the planner phase (~300ms) and embedding search (~200ms), where otherwise the UI would appear frozen.

How Rate Limiting Works: Redis-Backed Daily Quotas

The previous post covered the implementation. Here's how it manifests in the UX.

The rate_limit event is always the first SSE event, sent before any computation:

data: {&quot;type&quot;: &quot;rate_limit&quot;, &quot;used&quot;: 1, &quot;limit&quot;: 20, &quot;remaining&quot;: 19, &quot;resets_in_seconds&quot;: 36000}

The frontend updates the quota display immediately — users always know how many queries they have left:

{quota &amp;&amp; (
  &lt;div className=&quot;flex items-center gap-1.5 text-xs text-[var(--text-muted)]
                  glass px-3 py-1.5 rounded-xl border border-white/[0.06]&quot;&gt;
    &lt;span className={cn(&quot;font-medium&quot;,
      quota.allowed ? &quot;text-emerald-400&quot; : &quot;text-rose-400&quot;)}&gt;
      {quota.limit - quota.used}
    &lt;/span&gt;
    / {quota.limit} left · resets in {formatRemaining(quota.resets_in_seconds)}
  &lt;/div&gt;
)}

When the daily limit is exhausted:

data: {&quot;type&quot;: &quot;error&quot;, &quot;message&quot;: &quot;Daily AI call limit reached (20/20). Refreshes in 8h 15m.&quot;}

The page also calls GET /api/v1/rag/quota on mount to pre-fetch the remaining count before the user types — no one types a question only to hit a limit.

How Chat Sessions Work: Stateful Conversations

Every RAG query belongs to a chat session with full history:

class RagChatSession(Base):
    __tablename__ = &quot;rag_chat_sessions&quot;
    id: uuid.UUID
    user_id: uuid.UUID | None  # NULL for guest chats
    guest_id: str | None       # Cookie-based ID for anonymous users
    title: str                 # Auto-titled from first query

class RagChatMessage(Base):
    session_id: uuid.UUID
    role: str                   # &#x27;user&#x27; | &#x27;assistant&#x27;
    content: str
    citations: list[dict]       # [{&quot;title&quot;: str, &quot;slug&quot;: str}]

Explanation

The RagChatSession class represents a chat session, with attributes for session identification and user information.
The user_id attribute can be None, indicating that the chat may be initiated by a guest user, while guest_id stores an anonymous identifier.
The title attribute is automatically generated from the first query made in the chat session.
The RagChatMessage class models individual messages within a session, including the sender's role (either 'user' or 'assistant') and the message content.
The citations attribute allows for storing references related to the message, formatted as a list of dictionaries containing titles and slugs.

The done event includes a session_id so follow-up queries continue the same conversation. The backend loads the last 3 messages for the planner and the last 5 for the generator.

The session auto-titles itself from the first query — "How does the HNSW index work?" becomes a session name. Authenticated users can browse their history at /ask and pick up where they left off.

How the Error Recovery Chain Handles Failures

Failure Point	Detection	Recovery
Network drop mid-stream	`reader.read()` throws	Exponential backoff (up to 3 retries)
All AI providers down	Backend returns SSE error event	"AI features are currently unavailable"
Quota exhausted	Rate limit check fails	Show quota banner with reset timer
Empty knowledge base	No chunks found	"Knowledge base hasn't been created yet"
Out-of-scope query	Planner detects	"I'm specialized in software engineering…"
User cancels	AbortController fires	Graceful stop, no error shown

Each recovery path uses the same AlertTriangle icon with a consistent visual style.

How Gamification Creates a Feedback Loop

Every successful RAG query by an authenticated user awards 5 XP:

if user_id:
    user = await db.get(User, user_id)
    await process_activity(db, user)
    await award_xp(db, user, 5, source=&quot;ai_query&quot;)

Explanation

Checks if user_id is provided; if so, it proceeds to fetch the user from the database.
Utilizes await to ensure that database operations are performed asynchronously, improving performance.
Calls process_activity function to handle user-related activities after retrieving the user data.
Awards 5 experience points to the user through the award_xp function, specifying the source of the activity as "ai_query".

This is server-side and invisible to the frontend — but the next time the user checks their profile, the XP is credited. It creates a subtle loop: useful answer + reward signal = higher return rate.

The Admin Experience: Unlimited Queries

if is_admin:
    result = RateLimitResult(allowed=True, used=0, limit=9999, resets_in_seconds=0)

Explanation

The code uses a conditional statement to check if the variable is_admin is True.
If the condition is met, it creates an instance of RateLimitResult with specific parameters.
The parameters set allowed to True, indicating that the admin has permission, and initializes used, limit, and resets_in_seconds values.
This setup likely allows the admin to bypass rate limits in a system where such limits are enforced for regular users.

The frontend shows "9999 left" — useful during development and content auditing.

Production Metrics

Metric	Value
Average latency (P50)	2.3 seconds
P95 latency	4.1 seconds
Daily queries (avg)	47
Retry rate (network drops)	0.8%
Error rate (API failures)	0.3%
Avg cost per query	$0.012
Chat sessions created/day	12

Frequently Asked Questions

How does production RAG streaming work end-to-end?

A user types a question, the backend sends it through a reasoning planner (query rewriting + scope detection), then through an embedding provider for semantic search, retrieves relevant chunks from pgvector, assembles them into a prompt, and streams the LLM response token-by-token via SSE. The first event shows the user's daily quota, the second shows source citations, and subsequent events stream the answer.

Why not use WebSockets for streaming RAG responses?

SSE is simpler for unidirectional server-to-client streaming. It works over standard HTTP, doesn't require a protocol upgrade, auto-reconnects natively, and integrates cleanly with fetch() + ReadableStream for full control over authentication and abort.

How are RAG citations rendered in the frontend?

Source posts arrive as a sources SSE event with title and slug. The frontend renders them as clickable amber badges below the answer. Each badge links to the original post. There are no inline [1] markers — the badges provide attribution independently.

What happens when the network drops during streaming?

The frontend retries with exponential backoff: 1 second, then 2 seconds, then 4 seconds (max 3 attempts). The UI shows a "Connection lost — reconnecting…" status. If the user cancels, the AbortController stops all retries immediately.

How does rate limiting work for RAG queries?

Redis atomic counters track daily usage per user or IP. Guests get 3 queries per 24-hour rolling window. Free authenticated users get 20 per day (resets at midnight UTC). Premium subscribers get 100 per day. Admins get unlimited.

How are chat sessions tracked?

Every query belongs to a RagChatSession. The done SSE event includes a session_id. Follow-up queries include this ID, and the backend loads the last 3 messages for the planner and last 5 for the generator. Sessions auto-title from the first query.

Structured Data for AI Extraction

{
  &quot;@context&quot;: &quot;https://schema.org&quot;,
  &quot;@type&quot;: &quot;TechArticle&quot;,
  &quot;headline&quot;: &quot;Streaming, Citations &amp; Fallbacks: The Production RAG Stack&quot;,
  &quot;description&quot;: &quot;Production RAG with SSE streaming via ReadableStream, citation badges, Redis-backed daily quotas, exponential backoff reconnection, and chat sessions.&quot;,
  &quot;author&quot;: {
    &quot;@type&quot;: &quot;Person&quot;,
    &quot;name&quot;: &quot;Madhu Dadi&quot;,
    &quot;url&quot;: &quot;https://madhudadi.in&quot;
  },
  &quot;datePublished&quot;: &quot;2026-05-19&quot;,
  &quot;proficiencyLevel&quot;: &quot;Advanced&quot;,
  &quot;about&quot;: {
    &quot;@type&quot;: &quot;Thing&quot;,
    &quot;name&quot;: &quot;Production RAG Streaming&quot;
  }
}

What's Next

The next post covers AI-powered summaries — how the AISummary component extracts key takeaways from any post in three styles (bullets, ELI5, executive), how caching reduces costs by 90%, and how the summary prompts are structured for factual extraction without hallucination.

Built with FastAPI, React Server-Sent Events via ReadableStream, Redis, and zero third-party AI platforms.
By Madhu Dadi

Building a RAG Chat System: From Zero to Production in Building This Blog: A Production AI Platform

Madhu Dadi — Mon, 11 May 2026 09:43:19 +0000

Building a RAG Chat System From Zero

The "Ask AI" page on this blog is not a generic chatbot. It's a Retrieval-Augmented Generation system that answers questions using only the content from this site's posts, and it shows you exactly which post each part of the answer came from.

Here's how it works, from embedding to response.

Why RAG Instead of Fine-Tuning

Fine-tuning a model on blog content would:

Require retraining every time a new post is published
Risk hallucinating facts not present in the training data
Give no way to cite sources in the response

RAG solves all three: query the content at runtime, inject the relevant chunks into the prompt, and return the source citations alongside the answer. No retraining needed.

Architecture

User Question
    │
    ▼
[Embedding Model] ──→ Question Vector
    │
    ▼
[pgvector HNSW Index] ──→ Top-K Similar Chunks (by vector distance)
    │
    ▼
[tsvector Full-Text Search] ──→ Top-K Chunks (by keyword relevance)
    │
    ▼
[Hybrid Scorer] ──→ Weighted + Reranked Results
    │
    ▼
[Context Assembly] ──→ Prompt with top chunks + question
    │
    ▼
[LLM] ──→ Generated Answer + Source Citations
    │
    ▼
[Source Verification] ──→ Verify citations match chunks
    │
    ▼
[Streaming Response] ──→ SSE to frontend

Step 1: The Embedding Pipeline

Every published post is split into chunks and embedded. The chunks are stored in the rag_chunks table:

CREATE TABLE rag_chunks (
    id UUID PRIMARY KEY,
    post_id UUID REFERENCES posts(id) ON DELETE CASCADE,
    chunk_index INTEGER NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536),
    metadata JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

The embedding dimension (1536) comes from the model: text-embedding-3-small from OpenAI. The choice was pragmatic — it's the cheapest per-token of the high-quality embedding models and produces 1536-dimensional vectors that work well with pgvector's HNSW index.

Chunking Strategy

Posts are split on paragraph boundaries, not fixed token counts:

def chunk_post(content: str, max_tokens: int = 500) -&gt; list[str]:
    paragraphs = content.split(&quot;\n\n&quot;)
    chunks = []
    current = []

    for p in paragraphs:
        estimated_tokens = len(p.split())
        current_token_count = sum(len(c.split()) for c in current)

        if current_token_count + estimated_tokens &gt; max_tokens and current:
            chunks.append(&quot;\n\n&quot;.join(current))
            current = [p]
        else:
            current.append(p)

    if current:
        chunks.append(&quot;\n\n&quot;.join(current))

    return chunks

Why paragraph boundaries? Code blocks, lists, and blockquotes are semantic units. Splitting mid-paragraph would separate a code example from its explanation, making the chunk useless for both retrieval and generation.

Each chunk stores its chunk_index so the frontend can link back to the correct section of the post. Metadata includes the post slug, title, section heading, and URL.

Step 2: The HNSW Index

pgvector supports two index types for approximate nearest neighbor search: IVFFlat and HNSW. I chose HNSW for three reasons:

Faster build time — HNSW builds incrementally. IVFFlat requires a full rebuild when data changes.
Better recall at same speed — HNSW consistently achieves 99% recall at 10ms query time with my dataset size (~50K chunks).
No training required — IVFFlat needs a clustering step that depends on representative data. HNSW is parameter-free.

CREATE INDEX idx_rag_chunks_embedding ON rag_chunks
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);

The parameters:

m = 16 — each node connects to 16 neighbors. Higher = better recall, slower build. 16 is the sweet spot for datasets under 100K vectors.
ef_construction = 200 — the dynamic list size during construction. Higher = better index quality, slower build. 200 is conservative.

At query time, the search uses SET hnsw.ef_search = 40 — this controls the search breadth. Higher = better recall, slower query.

Step 3: Hybrid Search

Vector search alone misses exact keyword matches. "How do I install FastAPI?" matches the vector of "FastAPI installation guide" but misses the exact phrase match. Full-text search via tsvector catches what vector search misses.

The hybrid query combines both:

async def hybrid_search(query: str, limit: int = 10):
    query_embedding = await embed(query)

    vector_results = await db.execute(
        text(&quot;&quot;&quot;
            SELECT id, content, post_id, chunk_index,
                   1 - (embedding &lt;=&gt; :query_emb) AS vector_score
            FROM rag_chunks
            ORDER BY embedding &lt;=&gt; :query_emb
            LIMIT :limit
        &quot;&quot;&quot;),
        {&quot;query_emb&quot;: query_embedding, &quot;limit&quot;: limit * 2}
    )

    fts_results = await db.execute(
        text(&quot;&quot;&quot;
            SELECT id, content, post_id, chunk_index,
                   ts_rank(to_tsvector(&#x27;english&#x27;, content),
                           plainto_tsquery(&#x27;english&#x27;, :query)) AS fts_score
            FROM rag_chunks
            WHERE to_tsvector(&#x27;english&#x27;, content) @@ plainto_tsquery(&#x27;english&#x27;, :query)
            ORDER BY fts_score DESC
            LIMIT :limit
        &quot;&quot;&quot;),
        {&quot;query&quot;: query, &quot;limit&quot;: limit * 2}
    )

    return hybrid_rank(vector_results, fts_results, alpha=0.7)

The alpha parameter controls the weight between vector and keyword scores. 0.7 means 70% vector, 30% keyword — biased toward semantic understanding while still catching exact matches.

Step 4: Hybrid Ranking

Results from both searches are combined using Reciprocal Rank Fusion (RRF):

def hybrid_rank(vector_results, fts_results, alpha=0.7, k=60):
    scores = {}

    for rank, row in enumerate(vector_results):
        scores[row.id] = scores.get(row.id, 0) + alpha * (1 / (k + rank + 1))

    for rank, row in enumerate(fts_results):
        scores[row.id] = scores.get(row.id, 0) + (1 - alpha) * (1 / (k + rank + 1))

    ranked = sorted(scores.items(), key=lambda x: -x[1])
    return [chunk_id for chunk_id, _ in ranked[:10]]

RRF is simple, fast, and doesn't require training a learned ranker. The constant k=60 prevents any single ranking from dominating.

Step 5: Context Assembly

The top 5-10 chunks are assembled into a prompt. The system prompt is:

You are a technical assistant for Madhu Dadi — AI, Python &amp; Analytics Hub.
Answer the user&#x27;s question based ONLY on the provided context.
If the context doesn&#x27;t contain enough information, say so.
Always cite the source post title and section for each claim.
Format citations as [Source: Post Title → Section].

The user prompt includes the question and the chunk content:

Context:
[1] Post: &quot;Understanding Python Classes&quot; → Section: &quot;Class Methods&quot;
Content: Class methods are functions defined inside a class...

[2] Post: &quot;FastAPI Routes&quot; → Section: &quot;Path Parameters&quot;
Content: Path parameters are declared using Python type hints...

Question: How do I define a class method in Python?

Step 6: Source Verification

After the LLM generates a response, a verification step checks that each cited source actually exists in the provided chunks:

def verify_citations(response: str, chunks: list[dict]) -&gt; dict:
    citations_found = re.findall(r&#x27;\[Source: (.+?)\]&#x27;, response)
    valid_citations = []
    missing_citations = []

    for citation in citations_found:
        matched = any(citation in chunk[&quot;source&quot;] for chunk in chunks)
        if matched:
            valid_citations.append(citation)
        else:
            missing_citations.append(citation)

    return {
        &quot;verified_response&quot;: response,
        &quot;citations&quot;: valid_citations,
        &quot;unverified_claims&quot;: missing_citations
    }

Unverified claims are flagged but not removed from the response — they're marked with a warning icon in the frontend. This happens rarely (less than 2% of queries) and usually when the LLM rephrases a source name.

Step 7: The Database Model

class RagChunk(Base):
    __tablename__ = &quot;rag_chunks&quot;

    id: Mapped[uuid.UUID] = mapped_column(UUID, primary_key=True, default=uuid.uuid4)
    post_id: Mapped[uuid.UUID] = mapped_column(ForeignKey(&quot;posts.id&quot;, ondelete=&quot;CASCADE&quot;))
    chunk_index: Mapped[int]
    content: Mapped[str] = mapped_column(Text)
    embedding: Mapped[Optional[Vector]] = mapped_column(Vector(1536))
    metadata: Mapped[Optional[dict]] = mapped_column(JSONB)
    created_at: Mapped[datetime] = mapped_column(DateTime(timezone=True), server_default=func.now())

The Vector type comes from pgvector.sqlalchemy. It maps directly to PostgreSQL's vector extension type.

Cold Start: First User Experience

When a user visits the Ask AI page for the first time, there are no chunks to search. The solution: a pre-computed set of seed questions and answers, one per published post, generated during the embedding pipeline.

SEED_QUESTIONS = {
    &quot;why-i-built-yet-another-blog-but-not-really&quot;: [
        &quot;Why did you build your own blog platform?&quot;,
        &quot;What features does this blog have that others don&#x27;t?&quot;
    ],
    &quot;the-monorepo-that-runs-29-services&quot;: [
        &quot;How is the monorepo structured?&quot;,
        &quot;What are the 29 API routers?&quot;
    ]
}

These seed questions are embedded and stored alongside the post chunks. On the first page load, the frontend fetches 3-5 seed questions as suggestions. When the user clicks one, it triggers a RAG query, which populates the embedding cache. Subsequent queries hit the cache.

What's Next

In the the next post, I'll cover the production RAG pipeline — streaming responses via SSE, progressive rendering, citation badges, fallback strategies, rate limiting, and the cold-start UX flow in detail.

Built with FastAPI, Next.js 16, PostgreSQL, Redis, and zero third-party CMS. Deployed on a $12/month VPS.

By Madhu Dadi

The Monorepo That Runs 29 Services on a Single $24 VPS in Building This Blog: A Production AI Platform

Madhu Dadi — Mon, 11 May 2026 07:24:52 +0000

The Monorepo That Runs 29 Services

In the last post, I explained why I built this platform from scratch. Now let's open the hood.

This monorepo contains two applications — a FastAPI backend and a Next.js frontend — plus shared infrastructure configuration. Everything lives in one repository, deploys via one docker-compose.yml, and runs on one $12/month VPS.

Here's the directory structure, explained layer by layer.

Top-Level Layout

blog_platform/
├── fastapi_backend/     # Python API server (29 routers, 21 models)
├── blog_frontend/       # Next.js 16 app (React 19, Turbopack)
├── nginx/               # Reverse proxy config
├── docs/                # Architecture decisions, content plans
├── conductor/           # Feature specs and bug fixes
├── docker-compose.yml   # Single-file deployment
├── docker-compose.prod.yml
└── deploy.sh            # Zero-downtime deploy script

The two applications communicate exclusively through HTTP. The frontend never imports Python code, and the backend never references React components. The contract is the API schema — documented automatically by FastAPI's OpenAPI generation at /docs.

FastAPI Backend — `fastapi_backend/`

fastapi_backend/
├── app/
│   ├── main.py              # App entry, middleware, router registration
│   ├── config.py            # Settings from environment variables
│   ├── database.py          # Async SQLAlchemy engine + session factory
│   ├── dependencies.py      # Shared dependency injection (auth, db)
│   ├── core/                # Cross-cutting concerns
│   │   ├── limiter.py       # Rate limiting (slowapi + Redis)
│   │   ├── redis.py         # Redis connection pool
│   │   ├── scheduler.py     # APScheduler background jobs
│   │   ├── uploads.py       # File upload handling
│   │   └── exceptions.py    # Custom exception classes
│   ├── models/              # SQLAlchemy ORM models (21 files)
│   ├── schemas/             # Pydantic request/response schemas
│   ├── routers/             # API endpoint handlers (29 files)
│   └── services/            # Business logic layer
├── alembic/                 # Database migrations
├── tests/                   # Pytest test suite
├── uploads/                 # User-uploaded images, PDFs, data files
├── scripts/                 # Maintenance scripts
├── requirements.txt
├── Pipfile
└── Dockerfile

Entry Point — `main.py`

The application is assembled in main.py. Here's the skeleton:

app = FastAPI(title=&quot;Madhu Dadi — AI, Python &amp; Analytics Hub API&quot;, lifespan=lifespan)

app.add_middleware(TrustedHostMiddleware, allowed_hosts=settings.ALLOWED_HOSTS)
app.add_middleware(CORSMiddleware, ...)
app.add_middleware(SessionMiddleware, ...)

V1 = &quot;/api/v1&quot;
app.include_router(auth.router,        prefix=V1)
app.include_router(posts.router,       prefix=V1)
app.include_router(series.router,      prefix=V1)
app.include_router(comments.router,    prefix=V1)
# ... 25 more routers

The lifespan context manager initializes Redis and starts the background scheduler on startup, then tears them down on shutdown.

Settings — `config.py`

All configuration comes from environment variables via Pydantic's BaseSettings:

class Settings(BaseSettings):
    APP_NAME: str = &quot;Madhu Dadi API&quot;
    DEBUG: bool = False
    DATABASE_URL: str
    REDIS_URL: str
    SECRET_KEY: str
    CORS_ORIGINS: list[str]
    ALLOWED_HOSTS: list[str]
    # ... 30+ more settings

No hardcoded secrets. No .env files committed to git. Every deployment environment (dev, staging, production) supplies its own values through environment variables or Docker secrets.

Database — `database.py`

Async SQLAlchemy 2.0 with session-per-request pattern:

engine = create_async_engine(settings.DATABASE_URL, pool_size=20, max_overflow=10)
AsyncSessionLocal = sessionmaker(engine, class_=AsyncSession, expire_on_commit=False)

async def get_db() -&gt; AsyncGenerator[AsyncSession, None]:
    async with AsyncSessionLocal() as db:
        yield db

The expire_on_commit=False is intentional — it prevents lazy-loading issues after commit, which is a common pitfall in async SQLAlchemy.

The 29 Routers

Every API endpoint lives in app/routers/. Here's what each one does:

Router	Endpoints	Purpose
`auth.py`	6	Register, login, Google OAuth, token refresh, logout, email verification
`posts.py`	8	CRUD posts, list with filters, get by slug, toggle publish
`series.py`	5	CRUD series, list, get with progress, next/prev navigation
`comments.py`	4	Create, list (tree), delete (own), admin delete
`tags.py`	5	CRUD tags, list, merge duplicates
`bookmarks.py`	4	Add, remove, list user bookmarks, check status
`progress.py`	4	Mark read, get user progress, series progress, completion stats
`search.py`	2	Full-text search, hybrid vector search
`admin.py`	15	Post management, user management, analytics, tasks
`gamification.py`	6	XP leaderboard, badges, milestones, streak, level-up
`rag.py`	2	Ask AI (RAG query), get related chunks
`code.py`	1	Execute Python code (Pyodide sandbox)
`payments.py`	4	Stripe checkout, webhook, subscription status, plans
`referral.py`	3	Create referral code, track, leaderboard
`srs.py`	4	Spaced repetition review queue, submit review, stats
`quiz.py`	4	Generate quiz, submit answers, get history, leaderboard
`challenge.py`	3	Daily challenge, submit, leaderboard
`interview.py`	3	Start interview, answer question, get feedback
`notifications.py`	3	List, mark read, dismiss
`digest.py`	2	Email digest subscribe, unsubscribe
`newsletter.py`	3	Subscribe, confirm, unsubscribe
`uploads.py`	3	Upload image, upload PDF, upload data file
`redirects.py`	3	Create, list, resolve
`feed.py`	1	RSS/Atom feed generation
`recommendations.py`	1	Personalized post recommendations
`certificate.py`	2	Generate series completion certificate, verify
`study_notes.py`	3	Create, list, delete personal study notes
`settings.py`	2	Get/update user settings

That's 29 routers serving approximately 120 individual endpoints. Each router is between 50 and 300 lines. The admin.py router is the largest at ~500 lines because it handles post CRUD with all the tag/series/difficulty associations.

The 21 Database Models

All models inherit from SQLAlchemy's DeclarativeBase and live in app/models/:

class Base(DeclarativeBase):
    pass

Key models and their relationships:

Model	Key Fields	Relationships
`User`	email, password_hash, xp, level, streak	has_many: posts, comments, progress, bookmarks
`Post`	title, slug, content, status, difficulty	belongs_to: series; has_many: tags (M2M), comments, bookmarks
`Series`	title, slug, description	has_many: posts
`Tag`	name, slug	has_many: posts (M2M)
`Comment`	content, is_approved	belongs_to: user, post; self-referential: parent
`Bookmark`	—	belongs_to: user, post (unique constraint)
`UserProgress`	completed_at, read_time_spent	belongs_to: user, post
`Badge`	name, description, icon, criteria	has_many: users (M2M via UserBadge)
`Challenge`	day, question, answer, difficulty	has_many: submissions
`Payment`	stripe_session_id, status, amount	belongs_to: user
`Subscription`	stripe_subscription_id, status, plan	belongs_to: user
`RagChunk`	content, embedding (vector), metadata	belongs_to: post
`SrsCard`	ease_factor, interval, review_count, next_review	belongs_to: user, post
`Notification`	type, title, message, is_read	belongs_to: user
`Redirect`	old_slug, new_slug	—
`Referral`	code, reward_xp	belongs_to: user; has_many: referred users
`PostView`	viewed_at, ip_address	belongs_to: post (analytics)
`PostReaction`	reaction_type	belongs_to: user, post
`QuizAttempt`	score, total_questions, answers	belongs_to: user
`InterviewSession`	questions, answers, overall_score	belongs_to: user

The most interesting table is RagChunk. It stores post content split into chunks, each with a 1536-dimensional vector embedding. The search query is: find chunks whose embedding is closest to the query embedding, filtered by the user's premium tier. This is the core of the "Ask AI" feature.

Redis as the Glue Layer

Redis isn't a cache in this architecture — it's a service bus. It handles five distinct concerns:

1. Rate limiting — slowapi uses Redis as its backing store. Each endpoint family has its own limit (100/hr for anonymous, 500/hr for authenticated). The key is rate_limit:{ip}:{route_group} with a sliding window counter.

2. OAuth state — Google OAuth uses a redirect-based flow. The state parameter (a random token) is stored in Redis with a 10-minute TTL. After the callback, the token is verified and deleted. This prevents CSRF on the OAuth handshake.

3. Embedding cache — When a user asks the RAG system a question, the query is first checked against a Redis set of recent queries. If found within 5 minutes, the cached embedding is reused. This saves ~200ms per query on repeated questions.

4. Task queue — Redis pub/sub dispatches background tasks: email digests, content revalidation (purging Cloudflare cache), and maintenance jobs. The publisher pushes to a channel, and the APScheduler subscriber picks it up.

5. Leaderboard — XP rankings use Redis sorted sets (ZADD, ZREVRANK, ZRANGE). The leaderboard is recomputed every 5 seconds from a materialized PostgreSQL view, then stored in Redis for fast reads. This avoids sorting 10,000+ users on every page load.

Background Scheduler

app/core/scheduler.py runs four recurring jobs:

def start_scheduler():
    scheduler = AsyncIOScheduler()
    scheduler.add_job(send_daily_digests, &quot;cron&quot;, hour=8, minute=0)
    scheduler.add_job(regenerate_sitemap, &quot;cron&quot;, hour=2, minute=0)
    scheduler.add_job(clean_expired_tokens, &quot;cron&quot;, hour=3, minute=0)
    scheduler.add_job(check_stripe_subscriptions, &quot;interval&quot;, hours=1)
    scheduler.start()

Daily digests — queries the Post table for posts published in the last 24 hours, assembles an HTML email, and sends via SMTP to subscribed users.
Sitemap regeneration — queries all published posts and series, generates a fresh sitemap.xml, and pings Google/Bing.
Token cleanup — deletes expired refresh tokens from the database.
Stripe sync — checks for subscriptions that should have expired and marks them accordingly.

The scheduler runs inside the same Python process as the FastAPI app. No separate Celery worker needed.

Frontend — `blog_frontend/`

blog_frontend/
├── src/
│   ├── app/                  # Next.js App Router pages
│   │   ├── blog/             # Blog posts (dynamic routes)
│   │   ├── admin/            # Admin dashboard (protected)
│   │   ├── login/            # Auth pages
│   │   ├── register/
│   │   ├── profile/          # User profiles, settings
│   │   ├── series/           # Series index + detail
│   │   ├── tags/             # Tag index + filtered posts
│   │   ├── search/           # Full-text + vector search UI
│   │   ├── ask/              # RAG chat interface
│   │   ├── challenge/        # Daily coding challenge
│   │   ├── leaderboard/      # XP rankings
│   │   ├── milestones/       # Badges, progress, knowledge graph
│   │   ├── bookmarks/        # Saved posts
│   │   ├── layout.tsx        # Root layout with metadata defaults
│   │   ├── robots.ts         # Dynamic robots.txt
│   │   └── sitemap.ts        # Dynamic sitemap.xml
│   ├── components/           # Reusable React components
│   │   ├── admin/            # PostEditor, AnalyticsChart, etc.
│   │   ├── blog/             # MarkdownRenderer, PostCard, etc.
│   │   ├── layout/           # Navbar, Footer, CommandPalette
│   │   ├── ui/               # Button, Input, Spinner, GlassCard
│   │   ├── user/             # BadgeGrid, UserStats, KnowledgeGraph
│   │   ├── premium/          # PremiumGate, PlanSelectionModal
│   │   └── rag/              # RagChat overlay
│   ├── contexts/             # AuthContext, ThemeContext, LearningContext
│   ├── lib/                  # API client, utilities, types
│   └── workers/              # Web Workers (Python runner)
├── public/                   # Static assets
├── e2e/                      # Playwright tests
├── next.config.ts
├── tailwind.config.ts
├── vitest.config.ts
└── postcss.config.js

The API Client — `src/lib/api.ts`

The frontend communicates with the backend through a typed API client. Every endpoint is a function:

export const postsApi = {
  get: (slug: string, token?: string) =&gt; 
    apiFetch&lt;PostResponse&gt;(`/posts/${slug}`, { auth: true, token }),
  list: (params?: PostListParams) =&gt; 
    apiFetch&lt;PaginatedResponse&lt;PostListItem&gt;&gt;(`/posts?${toQuery(params)}`),
  create: (payload: CreatePostPayload) =&gt;
    apiFetch&lt;PostResponse&gt;(&quot;/posts&quot;, { method: &quot;POST&quot;, body: payload, auth: true }),
  // ... 5 more methods
};

The apiFetch wrapper handles:

Automatic JWT token injection from cookies or localStorage
401 → token refresh → retry (with debounce to avoid race conditions)
Error normalization (FastAPI validation errors → user-friendly messages)
Request deduplication for concurrent identical calls

Server Components vs. Client Components

Every page is a server component by default. Client components are only used where interactivity is required:

PostEditor — markdown editing, tag selection, image upload
RagChat — streaming chat UI with source citations
KnowledgeGraph — D3.js force-directed graph
Navbar/CommandPalette — user menu, keyboard shortcuts
ThemeToggle — dark/light mode

Server components handle everything else: data fetching, metadata generation, static params, and most of the rendering. This means the average page ships ~40KB of HTML instead of ~200KB of JavaScript.

Shared Infrastructure — `nginx/`

server {
    listen 80;
    server_name madhudadi.in;

    location /blog {
        proxy_pass http://frontend:3000;
        proxy_set_header Host $host;
    }

    location /api/ {
        proxy_pass http://backend:8000;
        proxy_set_header Host $host;
    }
}

Nginx handles:

Routing — /blog → Next.js frontend, /api → FastAPI backend
Caching — static assets (CSS, JS, images) cached for 1 year with hashed filenames
Compression — brotli for modern browsers, gzip fallback
Security headers — HSTS, X-Content-Type-Options, CSP, Referrer-Policy
Cloudflare integration — real IP headers, cache purging via API

The key insight: Nginx is the only entry point. There's no Kubernetes ingress, no cloud load balancer, no API gateway. One Nginx config handles everything.

What I'd Change

Looking back, there are three things I'd do differently:

1. Use a task queue from day one. The Redis pub/sub approach works, but it's not durable. If the app crashes mid-job, the task is lost. A proper queue (ARQ, Celery with Redis broker) would give retries, dead-letter queues, and job persistence.

2. Split the admin router. app/routers/admin.py at 500+ lines handles too many concerns. Post CRUD, user management, analytics queries, and task management should be separate routers. The file grew organically and never got refactored.

3. Add OpenAPI types to the frontend. The API client in src/lib/api.ts is manually typed. There's no code generation from the FastAPI OpenAPI schema. This means when the backend adds a field, the frontend type needs a manual update. Using openapi-typescript or orval would eliminate this class of bugs.

What's Next

In the next post, I'll dive into the RAG chat system — how embeddings are generated, how hybrid search works, and how the streaming response pipeline is built.

Built with FastAPI, Next.js 16, PostgreSQL, Redis, and zero third-party CMS. Deployed on a $12/month VPS.

By Madhu Dadi

Why I Built Yet Another Dev Blog (and Why You Shouldn’t)

Madhu Dadi — Mon, 11 May 2026 06:58:13 +0000

Why I Built Yet Another Blog — But Not Really

Every developer has a blog in 2026. Medium, Dev.to, Hashnode, Substack — the options are endless, most are free, and they solve the "I just want to write" problem perfectly well.

So why did I spend six months building my own?

Short answer: because I wanted to teach things that those platforms cannot support. Interactive code that runs in the browser. An AI that answers questions about the content you're reading. A spaced repetition system that schedules reviews based on your actual reading history. A gamification engine that rewards learning, not scrolling.

This is the story of why I built it, what the architecture looks like, and — over the next 14 posts — exactly how every piece works.

The Problem With "Just Write" Platforms

I started on Dev.to. Then moved to Hashnode. Then self-hosted WordPress. Then Ghost. Each migration was triggered by the same frustration: the platform constrained what I could teach.

Here's what I wanted to do that none of them supported natively:

Feature	Medium / Dev.to	Hashnode	WordPress	Ghost	This Blog
Interactive Python code cells	❌	❌	❌	❌	✅ WebContainer
AI chat grounded in post content	❌	❌	❌	❌	✅ RAG
Gamification (XP, badges, leaderboard)	❌	❌	❌ (plugin)	❌	✅ Native
Spaced repetition for learning	❌	❌	❌	❌	✅ SM-2
Structured data for AI crawlers (GEO)	❌	❌	❌ (plugin)	❌	✅ Manual
Premium paywall (not Medium's)	❌	❌	❌	✅	✅ Stripe
Code execution projects	❌	❌	❌	❌	✅ Monaco + WebContainer
Interview simulator	❌	❌	❌	❌	✅ AI-powered

Each ❌ above represents a constraint I was unwilling to accept. Teaching Python and AI means letting readers write and run Python. Teaching RAG means letting them query a real RAG system and inspect the responses. Teaching architecture means showing them the actual code that powers the site they're reading.

A static blog cannot do any of this.

Why Not Use a CMS?

WordPress with plugins can approximate some of these features. Ghost has a paywall. But here's the problem: every feature I wanted required deep integration. A RAG chat system isn't a widget you embed. It needs to:

Query the same database that stores the posts
Respect the same authentication and premium gating
Render citations that link back to post sections
Stream responses through the same edge infrastructure

Plugins operate in a sandbox. Custom code operates on the full stack. Once I accepted that I needed custom backend logic, the question became: how much do I build vs. rent?

I chose to build everything except the payment processor (Stripe). The bet was that the integration value — having one coherent system instead of six glued-together services — would be worth the initial build cost. So far, it has been.

Architecture Overview

The platform runs on three layers:

Frontend — Next.js 16 (Turbopack)

React 19 with App Router, server components, streaming SSR
Tailwind CSS for styling, framer-motion for transitions
Monaco editor, xterm terminal, D3.js knowledge graph in the browser
All routes under /blog subdirectory (for clean reverse-proxy routing)

Backend — FastAPI (Python 3.12)

29 API routers, 21 database models, async SQLAlchemy
PostgreSQL for persistence, Redis for caching + rate limiting + pub/sub
Background scheduler for digest emails, content revalidation, maintenance tasks
JWT-based auth with Google OAuth + email/password fallback

Infrastructure — Docker Compose

Four services: backend, frontend, PostgreSQL, Redis
Nginx reverse proxy with caching, brotli compression, security headers
Cloudflare for DNS, DDoS protection, edge caching
Single docker-compose.yml, zero external dependencies

The full stack runs on a $12/month VPS. No Kubernetes. No serverless. No vendor lock-in.

Key Design Decisions

1. FastAPI Over Django or Node.js

I chose FastAPI for three reasons:

Async-first — every database call, Redis operation, and LLM request is non-blocking
Pydantic schemas — request validation and response serialization are declarative, with automatic OpenAPI docs
Python ecosystem — the ML/AI tooling (sentence-transformers, PyTorch, spaCy) is Python-native. Running a separate Python AI service would have negated the simplicity of a monorepo

Was Django an option? Yes. But Django's ORM, while powerful, is synchronous by default. The async story in Django 5.x is still catching up. For a stack that makes 4-6 async I/O calls per page load, FastAPI's native async support eliminated an entire class of performance problems.

2. Next.js 16 Over a Static Site

Next.js was chosen for:

Server components — expensive data fetches (database queries, API calls) run on the server, only HTML ships to the client
Dynamic OG images — the /api/og endpoint generates share cards per-post without a separate service
ISR (Incremental Static Regeneration) — popular posts are cached as static HTML, revalidated on publish
Middleware — auth checks, redirects, and A/B tests run at the edge without touching the backend

The trade-off: Next.js is opinionated about file-based routing. The app/blog/[slug]/page.tsx convention means posts live at /blog/posts/{slug}. But the flexibility of having metadata generation (generateMetadata), static params (generateStaticParams), and server components in one file outweighs the routing quirk.

3. PostgreSQL Over a Document Store

Every post, user, comment, badge, and payment lives in a single PostgreSQL 16 database. Why not MongoDB?

Relations — the data is deeply relational. Users have progress on posts. Posts belong to series. Badges have criteria that reference multiple tables. SQL joins handle this naturally
JSON columns — for semi-structured data (user settings, post metadata), PostgreSQL's JSONB gives document-store flexibility with relational integrity
Full-text search — tsvector indexes power the hybrid search alongside pgvector embeddings. No need for Elasticsearch
pgvector — embedding storage and similarity search live in the same database as the content. One connection pool, one backup strategy

The architecture uses one primary database with Redis as a cache layer, not a secondary database.

4. Redis as the Glue

Redis does five things in this stack:

Session cache — OAuth state tokens, rate limit counters, email verification codes
Task queue — background jobs (email digests, content revalidation) via Redis pub/sub
Embedding cache — frequently queried post embeddings are cached to avoid recomputation
Rate limiting — slowapi backed by Redis for distributed rate limits across multiple workers
Leaderboard — sorted sets for real-time XP rankings without hitting PostgreSQL

Having one well-understood cache layer for all five concerns simplified operations. Redis rarely needs tuning, and when it does, INFO STATS + MEMORY DOCTOR usually points to the fix.

What This Series Covers

This is post 1 of 15. Here's what's coming:

Foundation: Why I built it (this post), the monorepo structure, deployment architecture

AI Features: RAG chat from zero, production streaming, AI summaries, GEO optimization for AI crawlers

User Systems: Gamification engine, spaced repetition algorithm, premium paywall with Stripe

Interactive Features: Browser-based Python execution (WebContainer), AI-powered interview simulator, knowledge graph from reading history

Infrastructure: Docker stack retrospective, SEO that works for dev blogs, honest build retrospective

Each post will include code excerpts, schema snippets, and the actual implementation decisions. No fluff, no "download my ebook," no paywalled content.

The Honest Trade-offs

Building from scratch gave me full control. It also gave me full responsibility.

What I gained:

Every feature integrates at the database level, not through API glue
No platform dependency — Medium could pivot to AI-generated content tomorrow, and it wouldn't affect this site
Full ownership of the SEO output — every <meta> tag, structured data block, and robots.txt directive is hand-tuned

What it cost:

Six months of evenings and weekends before the first post went live
Ongoing maintenance: npm audit, pip-audit, PostgreSQL updates, TLS certificate renewal
No built-in audience — Medium and Dev.to have discovery algorithms; self-hosted blogs have Google and word of mouth

Was it worth it? Every time a reader runs a Python snippet in the browser and sees the output render live, or asks the RAG chat a question and gets a source-cited answer, I know the answer is yes.

What's Next

Post 2: The Monorepo That Runs 29 Services →

In the next post, I'll walk through every directory in the monorepo, explain what each of the 29 API routers does, and show the database schema that ties it all together.

Built with FastAPI, Next.js 16, PostgreSQL, Redis, and zero third-party CMS. Deployed on a $12/month VPS.

By Madhu Dadi

I Knew Python Syntax But Still Couldn’t Solve Problems Here’s Why

Madhu Dadi — Mon, 04 May 2026 09:33:08 +0000

When I started learning Python, I did everything “right”:

Watched tutorials
Read blogs
Bookmarked dozens of resources

And yet…

When I tried to solve problems on my own, I got stuck.

Not because I didn’t know Python
but because I didn’t know how to think.

⚠️ The Real Problem With Most Tutorials

Most Python tutorials focus on:

Syntax
Features
“Here’s how this works”

But they skip the part that actually matters:

Why this approach works
When to use it
How to break down a problem

So you end up knowing things like loops, functions, and lists…

…but still freeze when you see a real problem.

🔁 What Learning Usually Feels Like
Watch tutorial → Understand example → Feel confident

Try problem → Get stuck → Google → Repeat

This loop is where most learners stay.

💡 What Changed Everything for Me

I stopped treating Python as topics…

…and started treating it as a thinking process.

Instead of just learning what, I focused on:

Concept → Why it exists → Pattern → Apply to problem

Example:
Learn loops
Understand iteration patterns
Apply to real-world problems (not just toy examples)

That shift made a huge difference.

🏗️ So I Built What I Needed

I wanted something that:

Connects concepts
Builds step-by-step
Focuses on problem-solving

So I built this:

👉 https://madhudadi.in/blog

A structured Python learning path:

Basics → Control Flow → Data Structures
Functions → Recursion → Time Complexity
Concepts → Problem-solving → Interview prep

Each step builds on the previous one.

No jumping around. No guessing what to learn next.

🔍 What Makes It Different

Every topic tries to answer:

Why does this exist?
Where is this used?
How do I apply this in a problem?

Because:

Knowing syntax doesn’t make you good at Python.
Understanding patterns does.

🎯 Who This Is For

This might help you if:

You feel stuck despite learning regularly
You jump between tutorials without progress
You want a clear roadmap
You’re preparing for coding interviews
🤝 Would Love Your Feedback

If you check it out:

👉 https://madhudadi.in/blog

Let me know:

What confused you?
What’s missing?
What should I improve?

🧩 Final Thought

There’s no shortage of Python content.

But there’s still a shortage of clarity.

That’s what I’m trying to build.

DEV Community: Madhu Dadi

Understanding the Production RAG Stack: Streaming and Citations in a Production AI Platform

Streaming, Citations & Fallbacks: The Production RAG Stack

How SSE Streaming Works in FastAPI: fetch() + ReadableStream

What the SSE Event Sequence Looks Like

Why the Frontend Uses fetch() Instead of EventSource

How the Frontend Dispatches Events

How Citation Badges Work: Before the First Token

How the Frontend Handles Network Drops: Exponential Backoff

How Status Indicators Keep Users Informed

How Rate Limiting Works: Redis-Backed Daily Quotas

How Chat Sessions Work: Stateful Conversations

How the Error Recovery Chain Handles Failures

How Gamification Creates a Feedback Loop

The Admin Experience: Unlimited Queries

Production Metrics

Frequently Asked Questions

How does production RAG streaming work end-to-end?

Why not use WebSockets for streaming RAG responses?

How are RAG citations rendered in the frontend?

What happens when the network drops during streaming?

How does rate limiting work for RAG queries?

How are chat sessions tracked?

Structured Data for AI Extraction

What's Next

Building a RAG Chat System: From Zero to Production in Building This Blog: A Production AI Platform

Building a RAG Chat System From Zero

Why RAG Instead of Fine-Tuning

Architecture

Step 1: The Embedding Pipeline

Chunking Strategy

Step 2: The HNSW Index

Step 3: Hybrid Search

Step 4: Hybrid Ranking

Step 5: Context Assembly

Step 6: Source Verification

Step 7: The Database Model

Cold Start: First User Experience

What's Next

The Monorepo That Runs 29 Services on a Single $24 VPS in Building This Blog: A Production AI Platform

The Monorepo That Runs 29 Services

Top-Level Layout

FastAPI Backend — fastapi_backend/

Entry Point — main.py

Settings — config.py

Database — database.py

The 29 Routers

The 21 Database Models

Redis as the Glue Layer

Background Scheduler

Frontend — blog_frontend/

The API Client — src/lib/api.ts

Server Components vs. Client Components

Shared Infrastructure — nginx/

What I'd Change

What's Next

Why I Built Yet Another Dev Blog (and Why You Shouldn’t)

Why I Built Yet Another Blog — But Not Really

The Problem With "Just Write" Platforms

Why Not Use a CMS?

Architecture Overview

Frontend — Next.js 16 (Turbopack)

Backend — FastAPI (Python 3.12)

Infrastructure — Docker Compose

Key Design Decisions

1. FastAPI Over Django or Node.js

2. Next.js 16 Over a Static Site

3. PostgreSQL Over a Document Store

4. Redis as the Glue

What This Series Covers

The Honest Trade-offs

What's Next

I Knew Python Syntax But Still Couldn’t Solve Problems Here’s Why

How SSE Streaming Works in FastAPI: `fetch()` + ReadableStream

Why the Frontend Uses `fetch()` Instead of `EventSource`

FastAPI Backend — `fastapi_backend/`

Entry Point — `main.py`

Settings — `config.py`

Database — `database.py`

Frontend — `blog_frontend/`

The API Client — `src/lib/api.ts`

Shared Infrastructure — `nginx/`