# Tinder’s migration to Elasticsearch 8

[Tinder](https://yomu.fyi/company/tinder) · Tinder · Apr 1, 2025

**Type:** Problem & solution

## Summary

Tinder modernized its recommendation system by migrating its core Elasticsearch infrastructure from an end-of-life Elasticsearch 6 deployment to Elasticsearch 8 on Kubernetes. The legacy setup relied on manual EC2 provisioning and custom scripts, preventing the engineering team from utilizing modern vector search capabilities while incurring substantial operational overhead. Tinder implemented Elastic Cloud on Kubernetes integrated with its in-house Infrastructure as Code framework, Scaffold, while refactoring custom Java ranking plugins to handle Elasticsearch 8 breaking changes like prohibited negative scoring. The migration was validated through offline benchmarking, online verification, and a three-wave A/B testing rollout. This transition completed with zero outages and under 0.2% data discrepancy, reducing p99 search latency by 12% to 56% and cutting annual infrastructure costs by over one million dollars.

## Context

By 2021, Tinder's core recommendation Elasticsearch clusters were running on version 6 approaching end-of-life. The infrastructure relied on Puppet, custom scripts, and manual EC2 provisioning without integration into Tinder's Scaffold Infrastructure as Code framework, causing high operational maintenance and environment inconsistencies. Furthermore, the legacy setup created bottlenecks, such as a model loading issue taking two months to debug, and lacked modern search features like vector search and embedding-based retrieval required to improve recommendation personalization.

## Approach / What changed

Tinder chose Elasticsearch over OpenSearch to preserve its custom Java scoring plugin and leverage mature Kubernetes support. The team adopted Elastic Cloud on Kubernetes (ECK), integrated it with Scaffold for automated deployments, and implemented service mesh transit encryption, ephemeral storage handling, and autoscaling. To navigate application-level breaking changes, engineers reworked custom scoring logic to handle Elasticsearch 8's prohibition of negative scoring. Deployment involved offline benchmarking, online validation in live services, and a phased three-wave A/B testing rollout to prevent disruption to user recommendation KPIs.

## Takeaways

- Tinder retained Elasticsearch instead of adopting managed AWS OpenSearch because OpenSearch lacked support for custom Java scoring plugins and had less mature Kubernetes tooling at the time.
- The migration required overcoming breaking changes in Elasticsearch 8, notably the prohibition of negative scoring, which demanded an overhaul of ranking logic to preserve recommendation order.
- The upgrade lowered p99 search latency by 12% to 56% and saved over $1M annually, but increased cross-AZ network traffic costs due to 4-AZ expansion and Elasticsearch's switch to adaptive replica selection.

**Tags:** [Elasticsearch](https://yomu.fyi/topic/elasticsearch), [Kubernetes](https://yomu.fyi/topic/kubernetes), [Migrations](https://yomu.fyi/topic/migration), [Recommendation Systems](https://yomu.fyi/topic/recommendation-systems), [Search](https://yomu.fyi/topic/search)

[Read original post](https://medium.com/tinder/tinders-migration-to-elasticsearch-8-1999748ed7f4)