DEV Community: Shourya Parashar

Building Archie: A System-Design Board That Asks Instead of Guessing

Shourya Parashar — Wed, 28 Oct 2026 19:22:19 +0000

On the first held-out eval run, Archie scored 91.2%. One of the three misses worried me more than the score: I told it to "connect the workers to the database", the board had two databases, and it quietly picked one.

Nothing crashed. The diagram just became wrong, and a wrong architecture diagram looks exactly like a right one. This post is about how I built Archie, and why the feature I care about most is the one that makes it stop and ask.

What Archie Is

Archie is a system-design board you talk to. You say "five replicas of the API" or "kill Redis", the diagram updates, and a simulator shows where the system saturates, which requests fail, and why. I built it for the Wispr Flow challenge at Hacker House Goa 2026, mostly by dictation, for two kinds of people: engineers sketching a design, and students practising system-design interviews.

Voice or typed commands that become graph edits
A live simulator: load, utilization (ρ), p50/p95/p99 latency, success rate, throughput and a monthly cost estimate
Failure injection: "Kill Redis" drops success from 96.3% to 54.5%, and the blast radius shows which components went hot
Interview mode: six problems, from a URL shortener to video streaming, with an interviewer that asks about your weakest point

Two Tiers, One Rule: Never Guess

Every command goes through two tiers, and both follow the same rule. If a tier isn't certain, it doesn't act.

The fast path is a deterministic parser with an anchored grammar. It resolves names like "the db", "it" or "postgres replica one" and handles commands such as "shard Postgres into two" in the browser. It runs at a P50 of 0.006 ms over 14,000 runs. On the 92-case eval set it handles only 8 cases, but all 8 are correct. It abstains on everything else, which is the point.

The AI tier gets whatever the fast path won't touch. The server sends the model a compact text form of the board, the simulator summary, the last few chat turns and the command. The model runs on a ladder of free-tier Gemini models with Groq as the fallback. It can only return one of five things: edits, a clarifying question, a confirmation request, an answer, or a no-op.

The model never edits the board directly. It proposes typed operations, the code validates them, and an invalid batch gets one repair attempt before it turns into a question. Operations apply atomically, so one bad operation changes nothing, and everything can be undone.

command
  → fast path (deterministic, certain or silent)
  → AI tier (Gemini → Groq) → proposed ops
  → validate as a batch → one repair → else ask
  → apply atomically → simulator re-runs → canvas updates

The Bug That Changed the Design

The guardrails were already there when I ran the held-out test split the first time. The model still saw "the database", found two candidates, and picked one with confidence. That was 1 false action out of 34 cases.

A prompt tweak would have been the quick fix. Instead I added a guard in code: when a reference matches more than one component, Archie asks "Which database?" with tappable answers. It doesn't depend on the model behaving.

The second run on the held-out split scored 97.1% (33 of 34) with zero false actions. Part of that jump is run-to-run variance on free-tier models, and I've written that next to the result in the repo. The zero false actions is the number I trust, because a guard in code enforces it.

A Simulator That Shows Its Math

Every edit re-runs a queueing model: M/M/1 per replica at steady state, with cache-aside reads, read replicas, sharding, queues with backlog and failover, plus a 10,000-sample Monte Carlo for latency. A 100-component system simulates in 2.39 ms at P95, so the board keeps up while you talk.

I didn't want the simulator to just paint a node red. The bottleneck gets a note with the arithmetic:

1,500 reads/s + 5,000 writes/s on 1 shard
(capacity 10,000 reads / 4,000 writes per shard)
→ ρ = 1.40 → 28.6% of its requests dropped

Those numbers are golden-tested against hand calculations. It's a teaching model, not a vendor benchmark, and the docs list every assumption.

The same engine powers interview mode. The SLO checklist (success rate, read and write p99, headroom, surviving any single failure, cost) is computed by the simulator, not judged by the model. The final scorecard combines those checks with a five-part rubric where every score has to cite evidence from your board.

Testing It Like It Matters

612 unit, property and contract tests (Vitest and fast-check)
260 end-to-end tests on desktop and mobile Chromium (Playwright)
0 serious or critical accessibility violations across 15 states, light and dark, desktop and phone
266.9 KB of gzipped initial JS on the board route, with a budget enforced in CI

One target I haven't hit: I wanted 95% of answers to cite only the simulator's numbers. On the test split it was 2 of 3. That's next, along with a multi-turn eval category.

Tech Stack

Next.js 16, React 19 and TypeScript, React Flow with ELK layout in a Web Worker, Zustand and IndexedDB for state, Hono for the API, Zod for validation, and Vitest, fast-check and Playwright for tests. It runs as a single Docker container on Render.

What I Took Away

A tool that edits something people trust has to be more careful than it is clever. Archie's accuracy barely moved when I added the clarifying guard, but I stopped worrying about what it would do with an ambiguous command.

Try It

Live: archie-rb2x.onrender.com (free hosting, so the first load can take about a minute)

GitHub: github.com/im-shourya/Archie

Open the 50k rps demo and try saying "shard Postgres into two".

Originally published on shouryaparashar.in.

Building a Voice RAG System Under a 200ms Latency Budget

Shourya Parashar — Sat, 05 Sep 2026 03:30:00 +0000

What happens when you combine Voice AI + RAG + multilingual retrieval, but give yourself a strict 200ms latency budget?

That was the challenge behind my HH Goa 2026 Task 2 project.

I built a voice-driven RAG system on the AI4Bharat MSMARCO-XI dataset, designed to retrieve relevant information, generate grounded answers, and gracefully refuse when the evidence isn't strong enough.

The Pipeline

Voice
  ↓
Speech-to-Text
  ↓
Query Guard
  ↓
Hybrid Retrieval
  ↓
RRF + MMR
  ↓
Grounded Answer
  ↓
Verification

What made it interesting?

Instead of relying only on vector search, I combined:

Dense retrieval
BM25+ sparse retrieval
Reciprocal Rank Fusion
MMR reranking
Multiple chunking strategies
Retrieval confidence checks
Prompt-injection protection
Grounding verification
Extractive fallback answers

The goal wasn't just to make the system answer.

It was to make it answer only when it has enough evidence.

The part I cared about most: latency

I instrumented every stage and benchmarked the complete pipeline.

The final results:

Metric	Result
P50	7.87 ms
P70	9.62 ms
P100	40.71 ms
Benchmark runs	927
Within 200ms	100%

I also tested the actual HTTP service separately, instead of relying only on in-process benchmarks.

A few lessons

The biggest takeaway wasn't a particular model or framework.

It was that good AI systems are often about making the right engineering trade-offs.

A bigger model isn't always better.

More retrieval isn't always better.

And sometimes the best answer is simply:

"I don't have enough evidence to answer that."

This project pushed me to think about RAG not just as retrieval + generation, but as a complete system with latency, reliability, safety, and verification built into the architecture.

Built with

Python · FastAPI · BM25+ · Dense Retrieval · RRF · MMR · Sarvam · Claude · Docker

If you're interested in the implementation, the complete project is here:

GitHub: https://github.com/im-shourya/HHGOA-TASK2

Built for HH Goa 2026 — Shortlisting Task 2.

AI #RAG #Python #LLM #MachineLearning #VoiceAI #InformationRetrieval

KanbanFlow

Shourya Parashar — Sat, 25 Apr 2026 20:37:33 +0000

I Built a Zero-Backend Kanban Board with React + TypeScript — Here's What I Learned

No server. No database. No login. Just pure React — and it actually works great.

Why I Built KanbanFlow
Every Kanban tool I used asked me to sign up, connect to a server, or pay for features I didn't need. I wanted something that just opened and worked — instantly, privately, offline.

So I built KanbanFlow — a fully-featured Kanban board that lives entirely in your browser. No account. No backend. No setup.

What It Does

Unlimited columns and tasks — fully customizable
Drag & drop task movement across columns
Priority tagging — High, Medium, Low, None
Due dates with overdue highlighting
Live search + priority filtering
Dark / Light theme toggle
Auto-saves to localStorage — data persists across sessions

Tech Stack

React 18 + Vite 5 + TypeScript 5 + Tailwind CSS + React Router v6

No Redux. No external state library. Just React's useState and useReducer — keeping it lean.

The Interesting Part — localStorage as a Database

Most people reach for Firebase or Supabase immediately. But for a personal productivity tool, localStorage is genuinely underrated.

// Auto-save board state on every change
useEffect(() => {
  localStorage.setItem('kanban-board', JSON.stringify(board));
}, [board]);

// Load on mount
const [board, setBoard] = useState<Board>(() => {
  const saved = localStorage.getItem('kanban-board');
  return saved ? JSON.parse(saved) : defaultBoard;
});

This pattern gives you:

Instant persistence with zero latency
Works completely offline
No auth, no API keys, no cost
Data stays on the user's machine (privacy win)

The tradeoff? No cross-device sync. For a personal board, that's totally acceptable.

Drag & Drop Without a Library

Instead of reaching for react-beautiful-dnd or dnd-kit, I implemented drag and drop using the native HTML5 Drag and Drop API — which kept the bundle size tiny.

const handleDragStart = (e: DragEvent, taskId: string) => {
  e.dataTransfer.setData('taskId', taskId);
};

const handleDrop = (e: DragEvent, targetColumnId: string) => {
  const taskId = e.dataTransfer.getData('taskId');
  moveTask(taskId, targetColumnId);
};

Project Structure

I kept the component tree flat and predictable:

src/
├── types/kanban.ts         # All types + constants
├── components/kanban/
│   ├── TaskCard.tsx
│   ├── KanbanColumn.tsx
│   ├── TaskForm.tsx
│   ├── Header.tsx
│   └── Toolbar.tsx
└── pages/
    └── Index.tsx           # Main orchestrator

One rule I followed: no component does more than one thing. KanbanColumn renders a column. TaskCard renders a card. Index.tsx wires them together.

Try It

Live: kanbanflow.shouryaparashar.in
GitHub: github.com/im-shourya/KanbanFlow

Built by Shourya Parashar — Full Stack Developer.

If you found this useful, drop a ⭐ on GitHub — it genuinely helps!