Qdrant 1.19 added a routing token, so a caller can ask for deterministic read routing: the same token
sends the same reads to the same replica. Kdrant has no way to send one, and the case it exists for is
one this client currently makes worse.
Read-your-own-writes is the case. A write goes to the primary and replicates asynchronously; a read
issued a moment later lands on whichever replica the server picked and may not see it yet. An
application that writes a point and immediately searches for it gets an answer that is correct for the
cluster and wrong for the user. Today the only lever Kdrant offers is wait = true on the write, which
is heavier than the problem: it blocks the writer to fix a reader.
A routing token is the lighter answer, and it is per request rather than per client, because the thing
that should be sticky is one user's session and not the whole application. So this is a field on the
read requests rather than on KdrantConfig, which means it touches the search, scroll, count and
retrieve builders and both engines.
Qdrant's own 2026 roadmap puts read-only replicas next to this, and the two belong together: a
deployment that adds read replicas for throughput is exactly the deployment where reads start landing
somewhere the writer has never spoken to.
Exit criterion: two reads carrying the same routing token are served by the same peer and a read
carrying a different one is not, asserted against a real multi-node cluster over both engines, and the
KDoc says what a token is for rather than what it is called.
Qdrant 1.19 added a routing token, so a caller can ask for deterministic read routing: the same token
sends the same reads to the same replica. Kdrant has no way to send one, and the case it exists for is
one this client currently makes worse.
Read-your-own-writes is the case. A write goes to the primary and replicates asynchronously; a read
issued a moment later lands on whichever replica the server picked and may not see it yet. An
application that writes a point and immediately searches for it gets an answer that is correct for the
cluster and wrong for the user. Today the only lever Kdrant offers is
wait = trueon the write, whichis heavier than the problem: it blocks the writer to fix a reader.
A routing token is the lighter answer, and it is per request rather than per client, because the thing
that should be sticky is one user's session and not the whole application. So this is a field on the
read requests rather than on
KdrantConfig, which means it touches the search, scroll, count andretrieve builders and both engines.
Qdrant's own 2026 roadmap puts read-only replicas next to this, and the two belong together: a
deployment that adds read replicas for throughput is exactly the deployment where reads start landing
somewhere the writer has never spoken to.
Exit criterion: two reads carrying the same routing token are served by the same peer and a read
carrying a different one is not, asserted against a real multi-node cluster over both engines, and the
KDoc says what a token is for rather than what it is called.