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
Apache Flink feeds item data into Vespa in real-time, ensuring new items are searchable within seconds.
▾ source quote
“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 send search requests to the middleware Golang service using a predefined flat search contract.
▾ source quote
“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
A HAProxy load balancer routes incoming query traffic to the stateless Vespa container nodes.
▾ source quote
“We use a HAProxy load balancer to route the traffic to the stateless Vespa container nodes”
4
Custom searcher query construction
Integration
Custom searchers construct YQL to call Vespa.
▾ source quote
“These custom searchers eventually construct YQL to call Vespa”
5
ML model inference for ranking
Ai action
Vespa applies integrated machine-learned model inference to make sense of data and rank results in real-time.
▾ source quote
“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 Vespa to validate performance before cutover.
▾ source quote
“incoming query traffic was served by Elasticsearch and shadowed to the Vespa item search”
7
A/B relevance validation
Validation
Search relevance was A/B tested across four iterations until results were satisfactory before full traffic switch.
▾ source quote
“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
◆ Does this fit your context?

Compare to your context

Tell us your scale, team, and constraints. We'll show what changes at your size, what fails at your scale, and whether this case is a fit, needs adaptation, or won't scale to you. Free demo, no signup.

Compare to your context →
~30 seconds · free
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

WHAT TO DO WITH THIS

Now compare it to your context

This case is one data point. Whether its pattern fits you depends on your volumes, your stack, and your exception load — that comparison is the step no case study can do for you.

Browse the Ecommerce ops cases →