A search index turns a large collection of searchable items into a structure that can be queried quickly. In this design, photo representations are stored as vectors: filters narrow the candidate set, vector similarity retrieves candidates, and a relevance model orders the results. section 13.5.2 section 15.5.2
Treat the index as an operational system with separate update and query paths:
- Generate vectors for searchable items and update the index in batch, typically daily. section 15.5.2
- Support on-demand initial creation and full re-creation when the core model changes. section 15.5.2
- Keep updates throughput-oriented, targeting roughly 10^5 items per day and larger reindexing jobs when required. section 15.5.2
- Keep queries latency-oriented, handling uneven traffic, peaks near 100 queries per second, and rapid scaling. section 15.5.2
Photo search service
A private HTTP endpoint accepts a query string, optional filters such as price or resolution, a version, a limit, and a request identifier. The service filters photos, retrieves nearby vectors, ranks them, and returns matching photo IDs with scores. Qdrant is considered because it can filter and fetch candidates at scale, but it requires production validation. section 13.5.2
``` GET /search?query=<query_string>&filters=<filters>&version=<version> &limit=<limit>&request_id=<request_id> ```
Use the endpoint shape to inspect how queries, filters, versions, limits, and request identifiers enter the search system. section 13.5.2
```
{
"results": [
{
"id": <photo_id>,
"score": <score>
},
...
]
}
```
Use the response shape to inspect how ranked item identifiers and relevance scores leave the search system. section 13.5.2
