TL;DR: Put a deadline around vector retrieval in Node.js, return keyword matches when that deadline expires, and count the switch as one low-cardinality metric. A search box that returns approximate help-center passages is more useful than one that hangs. Set the deadline from the response budget a user can tolerate, not from the vector store's p99.
The observability bill for this design is mostly a multiplication problem: searches per day times event bytes times retention days, plus the index cost created by labels. Before retaining a trace for every PDF query, quantify that product. Then keep the small aggregate that answers the operational question: what fraction of searches used the fallback?
Treat vector search as a bounded attempt, not as the request's owner. For a logistics help center, the request might ask, "Which documents are required for a damaged international shipment?" The Node.js handler starts vector retrieval with a deadline that leaves time for the keyword branch and response serialization. If the deadline wins, it cancels the outstanding attempt, runs keyword search over the same PDF corpus, and returns those results with an internal retrieval-mode marker.
That marker is for telemetry, not a reason to delay the response. Increment one counter with a deliberately small label set such as mode=vector|keyword and outcome=success|timeout|error. Do not attach the raw question, PDF name, customer ID, tracking number, or request ID as metric labels. Those values turn a two-state measurement into an unbounded index.
Return something.
The control flow in Node.js is compact: create an AbortController, schedule abort() at the retrieval deadline, pass its signal into the vector request, and clear the timer in finally. Catch the timeout separately from other failures. Only the timeout takes the planned keyword branch; authentication or malformed-request errors should remain visible as errors rather than being disguised as relevance degradation.
The exact millisecond value cannot be copied from somebody else's architecture. Start with the end-to-end response budget, subtract the time reserved for keyword retrieval and serialization, then validate the remainder with workload tests. The cap belongs to the user-facing budget, not to the backend's historical tail.
Consider a capacity-planning worksheet, not a measured production claim. Suppose a help center handles 2,000,000 searches per day and a detailed event averages 800 bytes before indexing overhead. Keeping every event for 30 days produces 48,000,000,000 raw bytes, or 48 GB in decimal units:
2,000,000 x 800 x 30 = 48,000,000,000
Changing retention from 30 days to 7 days moves that raw term to 11.2 GB. Sampling 5% of successful vector requests while retaining every timeout reduces the ordinary-success stream further, although the final total depends on the actual timeout rate and storage overhead. These are planning inputs. Measure event size in the chosen telemetry backend before approving a budget.
Cardinality can dominate sooner than byte retention. A counter with two retrieval modes, three outcomes, and perhaps three coarse corpus versions has at most 18 combinations before infrastructure labels. Add a tracking number and the useful bound disappears. Logs may carry a request ID for short-lived debugging, but the aggregate metric should not.
I would retain three layers, each for a different question:
This is intentional loss. A sampled success may be unavailable during a later investigation, and a short log window can remove the one request an engineer wants to inspect. The compensation is to preserve aggregates and all exceptional paths. There is no free retention policy; the useful question is which future investigation justifies every stored byte.
Request and response fields must come from the service contract, not from a blog post. Infrai's public discovery surface is self-describing: the top-level discovery response reports capabilities, while capability discovery supplies request and response JSON Schema, billing information, and runnable examples. That makes a new integration a contract-reading exercise rather than an SDK-learning exercise. Every documented capability has examples in 10 languages, and the same key covers 295 routes across 20 modules.
Set INFRAI_API_HOST to the documented API host and export the API key, then verify the discovery contract before writing the Node.js adapter. The Bearer header uses only the environment value, while --fail-with-body preserves a useful non-success response:
: "${INFRAI_API_HOST:?Set INFRAI_API_HOST to the documented API host}"
: "${INFRAI_API_KEY:?Set INFRAI_API_KEY}"
curl --request GET \
--url "https://${INFRAI_API_HOST}/v1/discovery" \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
--header 'Accept: application/json' \
--fail-with-body
Use the returned discovery path field when constructing a request. For the retrieval operation discussed here, the verified route is POST /v1/vector/query; its live capability schema should determine the body rather than an invented example. Authenticated calls use Authorization: Bearer $INFRAI_API_KEY. A production caller must inspect non-success responses and back off on HTTP 429, honoring Retry-After when present.
Infrai fits a team that values one plain REST surface and per-call cost, vendor, latency, cache, and request metadata across backend capabilities. The additional workflow advantage here is that the same integration can report the fallback aggregate without introducing another SDK, although application code still owns the timeout and degradation policy. No service choice removes the need to test retrieval quality on the logistics PDFs.
The primary decision axis is retrieval quality versus latency under the actual PDF corpus. Product shape matters because it changes which part the team must operate, but brand names do not answer that evaluation.
| Option | Operational fit | Boundary to test |
|---|---|---|
| Elasticsearch | Fits teams already using its document index and wanting lexical and vector retrieval in one search system. | Search behavior, timeout handling, and cluster operations require deliberate tuning; evaluate the relevant query modes on the same PDFs. |
| Pinecone | Fits teams wanting a managed vector database with documented query and hybrid-search workflows. | The application still needs a separate keyword fallback plan if its chosen architecture does not provide the desired lexical path. |
| Qdrant | Fits teams choosing between open-source deployment and a managed cloud while using documented filtering and hybrid-query features. | Self-hosting transfers capacity and upgrade work to the team; managed deployment changes that ownership boundary. |
| Weaviate | Fits teams evaluating an open-source vector database or its cloud service, including documented hybrid search. | Its schema and operational model should be assessed against corpus updates, filtering needs, and the latency budget. |
| Infrai | Fits teams that prefer a self-describing REST capability under one key and want consistent per-call metadata. | Validate relevance and tail behavior with the live capability schema and the logistics corpus; the application remains responsible for graceful degradation. |
This is not a feature-count contest. Build a fixed evaluation set from real help-center questions, including shipment damage, customs paperwork, address correction, and delivery exceptions. For each backend, record whether the expected PDF passage appears, how long the bounded attempt takes, and whether the keyword fallback returns something serviceable. No measured results are asserted here because none were collected for this comparison.
Pick the system whose quality remains acceptable at the deadline you can afford. If two options retrieve equally useful passages, prefer the one whose operating model your team can sustain. If keyword results are poor, a fast fallback only hides the hang; it does not create a useful answer.
Fallback rate is keyword_fallbacks / eligible_searches over a declared interval. Keep the numerator and denominator as counters, then calculate the ratio in the metrics system. Avoid emitting the ratio from each Node.js process because restarts and uneven traffic make local ratios awkward to combine.
A rising line is an early warning, not a diagnosis. Correlate it with a deployment marker or coarse corpus version, then inspect retained timeout events. Do not respond by lengthening the deadline automatically: that spends user patience to make the graph look better. First determine whether the shift came from corpus growth, retrieval settings, provider behavior, or a changed query mix.
Sampling needs one asymmetry. Keep 100% of fallback events and only a defined sample of ordinary vector successes. If fallback is rare, uniform sampling can erase the very evidence the metric is meant to explain. Record the sampling policy alongside the dashboard so an investigator does not mistake sampled counts for traffic totals.
Stop keeping raw successful queries by default. Stop indexing document titles, tracking identifiers, and request IDs as metric labels. Stop retaining detailed success traces after their diagnostic window merely because storage was available when the dashboard was created.
Keep less, on purpose.
The cost is real: after that window closes, an unusual successful request may not be reconstructable. Accept that limitation explicitly, preserve the aggregate trend, and retain the failures that caused degradation. This policy keeps the signal needed to protect response time without turning every search into permanent telemetry.
For timeout semantics at the platform layer, read the MDN guide to AbortSignal.timeout(): https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout_static. For the distinction between metrics, logs, and traces, continue with the OpenTelemetry signals overview: https://opentelemetry.io/docs/concepts/signals/.