What architectural changes would you make to support near-real-time search over data that changes thousands of times per second (e.g., a live feed)?

At thousands of writes per second, the write path becomes the bottleneck, and the architectural changes are about decoupling ingestion from indexing, keeping the write path cheap, and making new data searchable quickly without sacrificing query latency. The first change is to batch writes: instead of upserting points one at a time, buffer them in the application and upsert in batches of hundreds or thousands, with wait=False to avoid blocking on durability. Batching amortizes the WAL write and the segment insert cost. The second change is to tune the optimizer for high write throughput: raise indexing_threshold during the high-write period so the optimizer does not try to build and merge segments on every batch, and lower it during quiet periods to consolidate. The third change is to use a write-optimized segment sizing: many small segments are fast to write but expensive to query, so the optimizer thresholds must balance write throughput against query fan-out. The fourth change is to consider a two-tier architecture: a small, fast, in-memory hot tier for the most recent data, and a larger, on-disk cold tier for older data. The fifth change is to make the ingest pipeline resilient: use a durable queue between the source and Qdrant, and make upserts idempotent with deterministic IDs so retries are safe.

The mechanism that makes near-real-time search possible is that Qdrant's segment model accepts new writes into a small mutable segment that is immediately searchable, even before it is indexed. So a point that is upserted is visible to queries within milliseconds, even if the HNSW graph for its segment has not been built yet. The query falls back to a brute-force scan on the unindexed segment, which is fast for a small segment. The optimizer then indexes the segment in the background, which makes future queries faster. This is the core of Qdrant's near-real-time behavior: writes are always visible, and indexing happens asynchronously. The freshness/latency trade-off is that unindexed segments make queries slower, so there is a tension between keeping the write path fast and keeping queries fast. The right balance depends on the ratio of writes to queries and on how fresh the data needs to be. The other mechanism is the WAL, which provides durability and replication: at high write rates, the WAL becomes the throughput limiter, and its size and flush behavior must be tuned to avoid I/O contention.