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.