Ecommerce ops · Production

Vinted migrates item search from Elasticsearch to Vespa, cutting servers in half and improving search latency 2.5x

The problem

As Vinted's catalogue grew to around 1 billion active items, Elasticsearch hit its limits: shard and replica management became time-consuming and error-prone, hot nodes created load imbalances, and a 300-second refresh interval made updated listings slow to surface in search.

First attempt

The previous Elasticsearch setup required constant shard and replica tuning, generated persistent hot node load imbalances, imposed a 300-second refresh interval, and became operationally unwieldy as data and traffic scaled.

Workflow diagram · grounded in source
1
Real-time item indexing
integration
“we started writing directly from Apache Flink, which allows data to be fed into Vespa in real-time. This integration ensures our search index is always up-to-date, with new items being searchable within seconds”
2
Search request via Go gateway
trigger
“Product applications using search communicate with Vespa via the Golang service. This middleware Go service acts as a gateway, accepting search requests in a predefined flat contract that we call a search contract”
3
HAProxy traffic routing
routing
“We use a HAProxy load balancer to route the traffic to the stateless Vespa container nodes”
4
Custom searcher query construction
integration
“These custom searchers eventually construct YQL to call Vespa”
5
ML model inference for ranking
ai_action
“the integrated machine-learned model inference allows us to apply AI to make sense of our data in real-time”
6
Traffic shadowing to Vespa
validation
“incoming query traffic was served by Elasticsearch and shadowed to the Vespa item search”
7
A/B relevance validation
validation
“we began A/B testing the search relevance. To port the main search items query, it took about four A/B test iterations until the relevance of the results was satisfactory”
Reported outcome

Vinted halved its server count (to 60 nodes), improved search latency by 2.5x and indexing latency by 3x, cut change-visibility time from 300 seconds to 5 seconds, and increased ranking depth more than 3x to 200,000 candidate items — all under a single unified Vespa deployment with a significant business impact on search relevance.

Reported metrics
Server countcut the number of servers we use in half (down to 60)
Search latency improvement2.5x
Indexing latency improvement3x
Change visibility timefrom 300 seconds to 5 seconds
Show all 13 reported metrics
server countcut the number of servers we use in half (down to 60)
search latency improvement2.5x
indexing latency improvement3x
change visibility timefrom 300 seconds to 5 seconds
ranking depth increasemore than 3 times, up to 200,000 candidate items
active searchable itemsabout 1 billion
peak query throughputabout 20,000 requests per second
peak query latency (99th percentile)under 150 ms
daily feeding rate10,300 RPS
item update latency (99th percentile)4.64 seconds
max indexing throughput per deploymentup to 50k RPS
search relevance business impactsignificant business impact
unique Vespa deployments21
Reported stack
VespaElasticsearchApache FlinkVespa Kafka ConnectLuceneHAProxyPrometheus
Source
https://vinted.engineering/2024/09/05/goodbye-elasticsearch-hello-vespa/
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

Vinted halved its server count (to 60 nodes), improved search latency by 2.5x and indexing latency by 3x, cut change-visibility time from 300 seconds to 5 seconds, and increased ranking depth more than 3x to 200,000 c…

What tools did this team use?

Vespa, Elasticsearch, Apache Flink, Vespa Kafka Connect, Lucene, HAProxy, Prometheus.

What results were reported?

Server count: cut the number of servers we use in half (down to 60); Search latency improvement: 2.5x; Indexing latency improvement: 3x; Change visibility time: from 300 seconds to 5 seconds (source-reported, not independently verified).

What failed first in this deployment?

The previous Elasticsearch setup required constant shard and replica tuning, generated persistent hot node load imbalances, imposed a 300-second refresh interval, and became operationally unwieldy as data and traffic…

How is this ecommerce ops AI workflow structured?

Real-time item indexing → Search request via Go gateway → HAProxy traffic routing → Custom searcher query construction → ML model inference for ranking → Traffic shadowing to Vespa → A/B relevance validation.

Related ecommerce ops cases