Tinder’s migration to Elasticsearch 8

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.

Related reading

• Tinder · Jan 9, 2023

  Building Obsidian, Tinder’s Design System

  As Tinder scaled over a decade, maintaining visual consistency across its client applications became unsustainable and increased engineering overhead. To address this, the UI Platform team developed Obsidian, a unified design system combining design tokens, reusable components, and documentation. Designers define base and context tokens in Figma using the Tokens Studio plugin, which are then transformed by Style Dictionary into native artifacts for iOS, Android, and Web. Web developers integrate these tokens using Atomizer to generate static stylesheets, while a Zeroheight documentation portal and a custom token lookup tool assist legacy migrations. The ongoing migration has streamlined collaboration between designers and engineers, resolved styling ambiguities, and improved color contrast accessibility across platforms.

  Tinder

• Yelp · Aug 4, 2026

  Migrating a Large Flow Monorepo to TypeScript