How would you design a system that needs to support both 'search the last 24 hours' and 'search all history' with very different latency expectations?

The clean design is a hot/cold split with two collections: a small, in-memory, fully indexed hot collection for the last 24 hours (or some rolling window), and a large, on-disk, quantized cold collection for all history. Queries scoped to the last 24 hours go to the hot collection, which is small enough to be fully in RAM and fully indexed, so it serves in single-digit milliseconds. Queries over all history go to the cold collection, which is much larger but is queried less frequently and has a larger latency budget. For queries that need both, the application queries both and merges, or queries the hot collection first and falls back to the cold collection if needed. The rolling window is maintained by a background job that moves data from hot to cold as it ages out: it upserts the point into the cold collection and deletes it from the hot collection. The hot collection is sized so its full in-memory footprint fits comfortably in RAM, and the cold collection is sized for capacity, not for latency.

The mechanism that makes this work is that the two collections have different configurations, each optimized for its access pattern. The hot collection uses a small m and high ef for fast traversal, no quantization (or scalar quantization) for maximum accuracy, and is fully in memory so there is no disk I/O. The cold collection uses binary quantization with rescoring and on-disk storage for capacity, with a lower ef for lower cost. The rolling window keeps the hot collection bounded in size: at 10k events per second, a 24-hour window is 864M points, which is too large for a single hot collection unless the events are much smaller or the window is shorter. In practice the hot window is sized to fit in RAM given the budget, and the cold collection holds everything older. The query routing is at the application layer: a query with a time filter on the last 24 hours goes to the hot collection, a query with a broader time filter goes to the cold collection, and a query with no time filter goes to both and merges with a recency boost. The merge must handle the case where the same document exists in both collections during the migration window, which can be done with deterministic IDs and a deduplication step.

The trade-off is between latency and cost. A hot collection that fits in RAM is expensive because RAM is expensive, but it serves low-latency queries for the most recent data, which is what most interactive queries target. The cold collection is cheap per point but has higher latency. The split lets each collection be sized and configured for its access pattern, which is more efficient than a single collection that must satisfy both. The common mistakes are: (1) sizing the hot collection too large so it does not fit in RAM, which defeats the purpose; (2) not having a clean migration path between hot and cold, so points are duplicated or lost; (3) not deduplicating during the migration window, so queries return duplicates; (4) routing all queries to the hot collection and falling back to cold only when necessary, which is correct, but the fallback must be explicit; (5) not monitoring the hot collection's size so it does not exceed RAM. Version note: the on-disk HNSW and quantization features that make the cold collection cheap have evolved across releases. Verify the availability and behavior of these features on your version before committing to the design.

Version-dependent: the on_disk flags, quantization options, and the scroll/delete APIs have evolved across Qdrant releases. The rolling window migration is application-level and version-independent, but the performance characteristics of the hot and cold collections depend on the version's storage layout. Benchmark both on your version.