2.9 s
until a price cut is searchable, worst case
Batching and refresh are most of it. A title edit waits up to 2 s more to re-embed: 4.9 s. Target: p99 within 5 s.
Alert at 50,000 messages behind?
Bad: Count messages
That’s 10 s at the 5,000/s peak, but 144 s at night.
Good: Event-time lag
Now − source.ts_ms, taken at bulk ack. Page when p99 tops 10 s for 5 min.
Never rebuild in place. Build v8 beside v7, then swap.
Record Kafka offsets, load a snapshot, replay, validate, then one atomic alias call. v7 stays fed 48 hours for rollback.
“Red Kurtha under 500 for women”, understood in about 20 ms
Spell, transliterate, extract, classify. Colour stays a boost, because a wrong filter empties a good query.
50M→20
products per query, in 150 ms of stages
Each stage costs more per item and sees fewer. The priciest model, LambdaMART, sees just 200. 50 ms of the 200 ms budget stays spare.
Precision@5 ties at 0.8. NDCG picks the better ranker.
Gain 2^grade − 1, divided by log₂(rank + 1). B puts the grade-3 kurta first, so it scores 0.88 against A’s 0.63.
Searchers favour result 1 even when the top two are secretly swapped. Train the ranker on raw clicks?
Trust bias
A click means “better than what I skipped”. Use skip-above pairs, propensity weights and exploration.
Remember
Writes hit the database; CDC keeps an aliased index seconds behind. Each query is understood, retrieved by BM25 and kNN, fused, ranked in stages and hydrated within 200 ms. NDCG and A/B tests judge it.