Dating App (Tinder)

Blog / Dating App (Tinder)
Blog hero image

Overview

Introduction

Designing Tinder may seem straightforward at first glance, given its simple user interface: a user creates a profile, swipes left or right on other profiles, and if two users swipe right, a match is made.

However, as former CTO of Tinder Maria Zhang described it, Tinder is like an iceberg all the complexity is hidden beneath the surface. As we dive deeper into the system design behind Tinder, you'll begin to understand why this complexity exists and why the challenges of building such a platform are far more intricate than they might initially appear.

Requirements

  • Functional Requirements
    • User Profile Creation: Users should be able to create and manage their profiles, including uploading photos, writing a bio, and specifying their preferences.
    • Location-Based Recommendations: The system should provide users with profile recommendations based on their current location, ensuring relevance and proximity.
    • Preference Settings: Users should have the ability to customize their search preferences, such as setting a desired radius, age range, and other filters to refine recommendations.
    • Matching Mechanism: Implement a matching algorithm that allows users to swipe left (dislike) or right (like) on profiles, with a match occurring when both users swipe right.
    • Passport Mode: Provide a feature that allows users to change their location and receive recommendations from different geographical areas, enabling interaction with users in other cities or countries.
  • Non Functional Requirements
    • Scalability: The platform must be able to handle millions of users simultaneously, scaling efficiently as the user base grows and as usage spikes in specific regions.
    • Availability: The system should maintain high availability, ensuring that users can access the service without interruptions, even during peak times.
    • Low Latency: User interactions, such as swiping and loading profiles, should be smooth and responsive, with minimal delay, to maintain an engaging user experience.
  • Non Covered
    • Chat Functionality: The implementation of chat or messaging between matched users will not be covered here, as it is discussed in detail in our Messaging App system design.

Creating Profile Flow

  • Request Initiation
    • User Action: The user initiates the profile creation process by sending a POST request to the /api/profile API endpoint.
    • Modular Requests: This process can be divided into multiple POST requests, each handling specific aspects of the profile (e.g., basic information, preferences, and image uploads). This modular approach ensures that each component of the profile is processed independently, allowing for better error handling and data consistency.
  • API Gateway
    • Tinder API Gateway (TAG): Routes incoming HTTP requests to the appropriate backend services, in this case, the User Profile Service.
    • Additional Functions: TAG also performs several other functions including rate limiting, session management, bot detection, and request & response scanning. For the technical interview you won't have to go into more detail than this, but if you want to learn more about TAG, this is a great Tech Blog Post by Tinder.
  • User Profile Service:
    • Object Storage: The user's images are uploaded to an object storage service, such as Amazon S3. This storage solution is ideal due to its scalability, durability, and ease of integration.
    • Content Delivery Network (CDN): The images are distributed via a Content Delivery Network (CDN) to ensure they are delivered quickly and reliably to users across the globe. A CDN reduces latency by caching images in servers close to the user's location, improving the overall user experience.
    • Data Storage: The user's basic information and preferences are stored in the User Profile Database. DynamoDB is an excellent choice for this database due to its high scalability and low latency, which are essential to meet Tinder's large-scale and performance requirements.
    • Location Service: The user's location information and preferences are then sent to the Location Service for indexing.
  • Location Service Functionality
    • Elasticsearch will be used to implement searching for users because it is highly scalable, provides powerful full-text search capabilities, and supports real-time querying. Given that Tinder is a location-based service with a maximum search radius of 100 miles, it is inefficient to include distant users - such as those in London when serving a user in California. Storing all users in a single global index would lead to significant performance issues due to the large index size and the computational load required to process queries.
    • Therefore, to handle Tinder's scale, which includes millions of users, we will use a geographically optimized solution known as geosharding. This approach involves storing users who are physically near each other within the same shard. By reducing the index size that each query needs to search, geosharding significantly improves query performance and minimizes computational overhead.

      Tinder Medium Blog | Sharding Approach [1]

    • The challenge with geosharding is to ensure that the load is balanced across shards, avoiding the creation of "hot-shards" where certain shards become overwhelmed with data or queries. In practical terms as shown in the image above, there won’t be any users in cells over the ocean, however, large cities like New York or London may have millions of users within small geographic areas. To manage this, our service will calculate a load score for each shard based on factors such as user activity and density, ensuring that the distribution of users across shards remains balanced.

      Hilbert Curve - Tinder Medium Blog | Sharding Approach [1]

    • To implement geosharding, the system will leverages Google's S2 library, which uses a Hilbert curve to preserve spatial locality. A Hilbert curve is a type of space-filling curve that ensures that points that are close on the curve are also close in physical space, making it ideal for mapping geographic data in a way that maintains locality.

      Tinder Medium Blog | Sharding Approach [1]

    • The S2 library projects the Earth's surface onto a cube where each face of the cube is filled with Hilbert curve and subdivides it into cells, with each cell representing a specific geographic area. These cells are organized into a quadtree structure, where four smaller cells combine to form a larger cell.
    • By adjusting the size of these cells, the system creates geoshards that are tailored to balance load and performance effectively. For example, in densely populated areas, smaller cells (and thus smaller geoshards) are used to ensure that the load is evenly distributed. Each user is mapped to an S2 cell based on their location (latitude and longitude), and these cells are then grouped into geoshards.
    • When a query is made—such as a user searching for recommendations within a 100-mile radius, the system will first determine which S2 cells fall within the search area. These cells are then mapped to the corresponding geoshards, which are the specific Elasticsearch indexes that need to be queried. By querying only the relevant geoshards, the system optimizes search performance and minimizes unnecessary computation.

      Adapted from Tinder Medium Blog | Sharding Approach [1]

    • In summary, Tinder’s use of geosharding with the S2 library allows it to efficiently manage a global user base, ensuring that search queries are fast, scalable, and geographically relevant.
  • Workers
    • Kafka Integration: After the Location Service identifies the appropriate S2 cell for the user, it pushes a message onto Kafka. Kafka ensures strict message ordering, crucial for maintaining consistency in location updates.which will be discussed in depth below in the Updating Location Flow.
    • Mapping Cache: Workers pull messages from Kafka and query the Mapping Cache (Redis) to determine the geoshard corresponding to the S2 cell. Redis is preferred here because the mapping is infrequently updated, making it ideal for caching purposes.
    • Document Creation: Finally, the worker creates the user document in the correct geoshard , ensuring that the user's profile is accurately stored and indexed based on their location.

Swiping Flow

  • User action
    • The user performs a swipe action in the Tinder app. This action is sent through an established websocket connection.
  • API Gateway
    • Tinder API Gateway (TAG): Manages websocket connections for all active users and handles authentication and initial connection setup. Once the WebSocket connection is established, TAG routes the swipe action to the appropriate backend service for processing.
  • Websocket Server
    • Receives swipe actions directly from users through the established WebSocket connections.
    • Pushes swipe information onto the Swipes Queue (e.g., Kafka) for asynchronous processing, ensuring that actions are handled in the order they are received.
    • The WebSocket Server keeps the WebSocket connections open with active users, enabling bidirectional communication for real-time notifications.
  • Swipes Queue
    • This queue temporarily holds all incoming swipe actions, providing a buffer that helps manage load and ensures that swipe actions are processed in a scalable and efficient manner.
  • Workers
    • Workers pull messages off the Swipes Queue for processing. The swipe information is stored in the Swipe Database (Swipe DB), ensuring that all actions are persisted for future reference.
    • If the swipe is a "like" (right swipe) then store it in the Likes Cache (Redis) for quick access. It will also check if the other user had previously liked the current user.
    • If it's a match push a match notification onto the Notification Queue.
  • Notification Queue
    • This queue holds match notifications, ensuring they are processed in the correct order and delivered reliably.
  • Match Notification Service
    • This service pulls match notifications from the Notification Queue and processes the match data.
    • After processing, the Match Notification Service sends the match information back to the WebSocket Server, which then communicates the match details to the user via the open WebSocket connection, providing real-time feedback.

Generating Recommendations Flow

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet.

Updating Location Flow

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet.

Complete Architecture

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet.

Additional Discussion Points

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet.

Master System Design Interviews

Get ready for the exact system design questions top tech companies are asking right now. Read comprehensive editorial write-ups and practice with our AI whiteboard that simulates a real, step-by-step interviewer experience.

See All System Designs →