2026 / ASYNC AI INFRASTRUCTURE
C-Flux.
What happens when a RAG pipeline has to serve more than one user at a time?
An asynchronous RAG pipeline that answers questions grounded in a user's own documents, without blocking on parsing, embedding, or inference.
Backend implemented · interface and hardening still in progress
Node.js · WebSockets · Redis · Pinecone · Gemini
THE USEFUL OUTCOME
What this makes possible.
A document-question-answering backend that moves parsing, embedding, and inference into background jobs.
THE ENGINEERING SIGNAL
What the work demonstrates.
Separated REST requests, WebSocket delivery, Redis queues, and background workers.
Why I Built It
I built C-Flux to learn how document AI systems can separate expensive processing from user requests, and to work with LLM APIs.
The Problem
A naive pipeline performs document parsing, embedding, and inference inside a blocking request flow. That doesn't scale once concurrent users show up.
The Decision
I split the architecture into a REST API, a WebSocket layer, a Redis queue, background workers, and Redis pub/sub — moving expensive work off the request path while still streaming results back to the correct client.
What Changed
Expensive processing runs in background workers while the API accepts jobs. This is an architectural improvement; throughput and load-test results have not yet been established.
What I'D Fix Next
Retrieval quality still needs work, error handling needs to be more robust. The next direction is making it more agentic — deciding what to do rather than following fixed steps.
HAVE A RELATED CHALLENGE?