Should Document Ingestion for RAG Be Synchronous or Event-Driven?

Embedding a document synchronously, as part of the request that creates or updates it, means the caller waits for that embedding call to finish, and if the embedding provider is slow or briefly unavailable, that latency or failure propagates directly to whatever created the document in the first place. This coupling is fine at low volume with a reliable embedding provider, and it becomes a real liability the moment either the embedding step gets slower or the source system's own reliability shouldn't depend on your RAG pipeline's health.

Dropping a change event onto a queue and letting a separate worker handle embedding and indexing means the source system's own request finishes immediately, regardless of how long embedding takes or whether the vector database is briefly unavailable. The tradeoff is a delay between a document changing and it becoming searchable, and a new piece of infrastructure, the queue itself, that has to be operated, monitored, and have its own failure modes accounted for.

If your corpus draws from several source systems, a support ticket system, a document store, a wiki, each with its own change frequency and reliability profile, a shared queue gives you one consistent ingestion pattern instead of custom synchronous integration code per source. It also means an outage in the embedding pipeline doesn't cascade back to every source system simultaneously; events simply queue up and process once the pipeline recovers.

A queue-based system needs an answer for what happens if the same document's update event arrives twice, or if two updates to the same document arrive out of order. Design ingestion to be idempotent, so processing the same event twice produces the same end state, and use a document version or timestamp to detect and discard an out-of-order update rather than letting a stale event silently overwrite a newer one.

The event-driven pattern trades immediate consistency for resilience, but only if you're watching for the failure mode it introduces: a growing backlog of unprocessed events, which means your index is falling behind what's actually true in the source systems. Alert on queue depth and processing lag directly, since without that visibility, a stalled ingestion worker can quietly leave your search results stale for hours before anyone notices.

Low document volume, a single reliable source, and a team still building the pipeline favor synchronous ingestion for its simplicity. Higher volume, multiple sources, or a source system that genuinely can't tolerate coupling to your RAG pipeline's latency favor an event-driven approach. Neither is the objectively better architecture; the right one depends on constraints that are worth stating explicitly rather than assuming.

It's also fine to run both at once, deliberately: synchronous for a low-volume, latency-sensitive source, event-driven for a bulk source that updates in large batches, as long as each pattern's tradeoffs are understood for the specific source it's applied to, rather than the whole pipeline being forced into one uniform pattern for consistency's sake alone. Write down which pattern applies to which source and why, so the mixed approach reads as a deliberate design decision to the next engineer who touches it, not as leftover inconsistency from two different eras of the codebase.

Check these points before moving ingestion onto a queue:

• Is ingestion volume or the number of source systems growing enough that synchronous embedding is slowing down or destabilizing the systems that create documents?
• Can the source system's own reliability be decoupled from your embedding provider's slowness or outages?
• Is ingestion idempotent, so processing the same event twice ends in the same state, with versions or timestamps to discard stale updates?
• Are queue depth and processing lag monitored and alerted on, so a stalled worker cannot quietly leave the index out of date?
• Is the delay between a document changing and becoming searchable acceptable for your users?