Status: Current-state analysis
The current architecture is intentionally simple and managed-service heavy. That keeps the project compact while creating clear scaling and latency constraints.
| Decision | Benefit | Trade-off | Why it works now |
|---|---|---|---|
| Client-side PDF parsing | Less server CPU and simple deployment | Large PDFs can consume browser CPU/memory | Suitable for moderate documents during early growth |
| Vercel Blob | Managed binary storage | DB and storage cannot share one transaction | Keeps PDFs out of MongoDB |
| Sequential Mongo writes | Easy to understand | More round trips and rollback paths | Simple business flow |
| Browser → Vapi | Low application-server media load | Voice path depends on an external platform | Keeps real-time media separate from app logic |
| Text search | Simple and debuggable | Semantic matches can be missed | Lowest infrastructure complexity |
| Synchronous ingestion | Straightforward upload flow | User waits for parsing/indexing | Acceptable before ingestion becomes a workload |
| Compensating rollback | Handles MongoDB + Blob consistency | More failure logic | Needed because storage is separate |
| Fixed 60-second cap | Simple guardrail | Not plan-aware or server-authoritative | Useful before billing is wired up |
Parsing the document in the browser removes a dedicated parsing worker and keeps the upload architecture compact.
The cost is browser resource usage. Very large files can increase memory pressure and make the upload experience dependent on device performance.
Future direction: retain client-side preview generation where useful, but move heavy ingestion to an asynchronous worker.
MongoDB transactions can protect the database part of the workflow, but they do not make Blob storage transactional.
The current system therefore uses compensating actions:
Blob PDF ✅
Blob cover ✅
Mongo PDF ✅
Segments ❌
↓
cleanup database state
+
cleanup Blob assets
This is more code than a single database transaction, but it matches the actual distributed boundary.
Text search keeps the retrieval service easy to test and reason about. The limitation is that lexical matching may fail when the user asks a question using terminology different from the document.
A future hybrid retrieval layer can combine lexical search, semantic similarity, metadata filtering, and ranking.
The browser-to-Vapi path avoids turning Next.js into a media relay. However, the full answer latency now crosses multiple systems: