EU users see yesterday's documents while US users see today's. Debug this geo replicated vector deployment.

MCQ·Medium·4.0 · 0·~1 min·Asked atDatabricks Humanloop Unity

Attempt it

The deployment has one primary region (US) and a read replica in the EU. Writes go to the primary. The primary streams those writes to the EU replica, which applies them in order. EU users query the local replica because it gives them low latency. The staleness comes from the replication stream. Two failure modes show the same symptom: - **Apply lag.** The change stream from US to EU is backed up. New writes are queued in the pipeline; the EU replica has not received or applied them yet. - **Index refresh paused.** The EU replica received the writes but has not yet folded them into its searchable index segments. The vectors sit in a write log waiting for the next refresh cycle. A day of staleness is a big deal. Normal replication lag is seconds to low minutes. Twenty-four hours means the pipeline stalled, the replica is paused, or the index refresh job is broken on the EU side. The first three things to check: replication lag metrics on the EU replica, the apply worker process logs for crashes or back-pressure, and the index refresh schedule for that region. The other answer choices distract toward embedding spaces or legal rules that do not produce time-shifted reads.

**Asynchronous replication, async by design.** The US primary owns writes; the EU replica serves local reads after asynchronously applying the change stream. Normal lag is seconds; 24 hours is a stalled pipeline. **Where to look, in order.** First, replication lag on the EU replica: the gap between primary LSN/sequence and applied LSN/sequence. If the gap is hours, the apply worker is stuck or backpressured. Second, the apply worker process: log for crashes, restarts, or rate-limit signals from downstream. Third, the index refresh job on the EU replica: replicated writes may be applied to the storage layer but waiting to be folded into searchable segments. Four, network: throttling, cross-region bandwidth caps, or a recent egress policy change. **Why the distractor answers fail.** A different distance metric reorders results within the same dataset; it cannot make yesterday's writes appear instead of today's. Embeddings are computed once at write time in a single embedding service; regional embedding drift would produce wrong-document ranking, not a clean 24-hour time shift. GDPR does not impose result delays. **The diagnostic signal.** A clean time shift (everything older than 24h is present, everything newer is missing) is unambiguous: replication or refresh lag. A noisy mix (some recent docs present, some missing) suggests partial apply, shard imbalance, or a failed batch. The clean-shift symptom narrows the diagnosis to the pipeline layer immediately.

TL;DR

Geo-replication is async. The EU replica is behind on either the replication apply stream or the segment refresh that promotes new writes into the searchable index. Replication lag, not regional embedding drift.

Memory aid

Easy to grasp

Think of a newspaper printed at one big plant in New York. Every other city in the world gets copies trucked to its local newsstands. If the trucks to Berlin are stuck in port for a day, Berlin readers see yesterday's headlines while New York readers see today's. Nothing is wrong with the news itself. Vector databases work the same way. The US primary is the printing plant. The EU replica is the Berlin newsstand. Writes ship as a change stream that the EU replica applies in order. If the stream backs up, or if the EU replica is busy and pauses the index-refresh step that makes new vectors actually searchable, EU users keep seeing yesterday's documents until the backlog drains. The fix is in the pipeline, not in the embeddings or the metric.

Key concepts

Vector Databases

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Geo-replicated vector deployments serve low-latency reads to users near their region while writes funnel to a primary. The architecture is the same one relational databases have used for decades: one writer, many async readers. The vector twist is that 'apply' has two stages, storage-level and search-visibility-level, and either can stall independently.

This walkthrough covers why async replication is the default in 2026, the two-stage apply pipeline, the diagnostic tree that isolates which stage is stuck, why the distractor answers in the question are structurally impossible, and the recovery postures available once you have diagnosed the problem.

Mental model: the primary owns writes, every region owns reads. The change stream is a queue. A 24-hour staleness is the queue draining slowly, not the data being wrong.

The topology that produces the symptom

A primary-plus-replicas vector deployment looks like this: writes hit the primary in one region (say us-east-1), the primary commits durably and emits a change event onto a replication stream, each replica region subscribes to that stream and applies events in order.

The apply has two parts. Storage apply writes the vector to the replica's durable store. Index refresh folds the new vector into the searchable HNSW or IVF segments. Both must complete for a query in that region to return the new document.

Normal lag is seconds. A 24-hour staleness means one of those steps is stuck. The pipeline did not lose the data; it just has not processed it yet. That is why the symptom is a clean time cutoff: writes before some moment are visible, writes after are not. Replication queues drain in order, and the cutoff is wherever the apply pointer currently sits.

The other answer choices in the question imagine failure modes that do not produce this shape. A different distance metric would reorder existing results, not insert a date cut. An embedding model that varied by region would produce non-comparable vector spaces, manifesting as cross-region recall collapse, not a one-day shift. Regulatory delays are not a real operational concept; regulators set obligations on processing, not on response timing.

The diagnostic tree

Why the distractors are structurally impossible

Recovery postures and SLO design

Geo-replication semantics: 2026 patterns and read-your-writes

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Pinecone serverless documents replication-lag metrics per region and recommends alerting at sub-minute thresholds for production workloads.
MongoDB Atlas Search (vector capabilities since 2024) exposes oplog apply lag as the primary signal for cross-region staleness, and the same playbook applies.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you set the replication-lag SLO for a search product where users expect new uploads to be findable in under a minute?

Decompose the budget. Embedding service latency (a few seconds), primary write commit (sub-second), cross-region apply (target under 30 seconds), index refresh (target under 30 seconds). Set the SLO at 90 seconds with paging at 5 minutes. The SLO is a product promise as much as an infra commitment.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Reaching for embedding drift or metric differences when the symptom is a clean time shift. Time shift is a replication-pipeline tell, not an embedding-space tell.

60 second bullets to scan on the way to the call.

Async geo-replication trades consistency for read latency, by design
Apply lag vs index-refresh lag are different subsystems with the same symptom

Primary sources. Browse if you want the original framing.