System Design: TINDER as a microservice architecture

Overview / approach

This is a system-design walkthrough for modeling a Tinder-like service as a microservice architecture.

Two high-level design approaches:

• Data-first: start with ER diagrams → services → clients. More constrained and abstract.
• Feature-first (recommended for interviews): start with user features, decompose front-to-back into services, then design each service’s data. Better for incremental design and interviews.

Advice for interviews:

• Pick ~4–5 core features to focus on.
• Ask clarifying questions (e.g., active users, images per profile, expected latency).
• Keep scope controlled and explain trade-offs rather than implementing every detail.

Core product features chosen

1. Storing user profiles (including images)
2. Recommendation / match discovery
3. Recording matches (who matched with whom)
4. Direct messaging (chat) between matches

Design decisions and components

Profiles & images

• Use an object store / distributed file system (S3-like) for images; store image URLs or image IDs in the database rather than blobs.
  • Reasons: immutability, lower cost, optimized for large objects, easy CDN integration, and avoids ORM/DB pitfalls for large binary data.
  • DBs’ advantages (transactions, indexes, mutability) are usually unnecessary for images; file stores with proper ACLs suffice.
• Serve images via CDN for global low-latency access.

Authentication & gateway

• Put an API gateway in front of all clients.
  • Gateway validates tokens and routes requests to microservices.
  • Centralized auth avoids duplicated authentication logic across services.

Image service

• A dedicated Image Service:
  • Stores images in the object store and maintains a DB table mapping profileID → imageID → imageURL.
  • Separates heavy I/O from profile metadata and enables reuse by other services (e.g., ML).

Matches service (match storage)

• Dedicated Matches/Matcher service as the source-of-truth for match relationships.
  • Store reciprocal entries (A→B and B→A) and index by userID for efficient lookups.
  • Matches must be saved server-side so they survive reinstall/restore.
  • When a message is sent, the matcher verifies that the two users are matched.

Direct messaging (chat)

• Persistent connections are preferred for real-time push: WebSocket or XMPP/TCP rather than HTTP polling.
• Use a Sessions service to map userID → active connection/socket (which gateway node / connection id).
• Typical message flow (simplified):
  1. Client → Gateway (gateway authenticates/forwards).
  2. Gateway → Matcher validates that users are matched.
  3. Gateway asks Sessions service for recipient connection info.
  4. Deliver message over the recipient’s persistent socket.
• Keep connection-state management decoupled from the gateway to avoid duplicated state and to scale horizontally.

Recommendation service (match discovery)

• Core problem: find nearby users filtered by age/gender/preferences at scale.
• Primary data: location (spatial), age, gender, and other filters. Location is the primary query dimension.
• Two database/indexing approaches:
  1. NoSQL / query-pattern replication (Cassandra, Dynamo, etc.):
     • Replicate user data into multiple tables tuned to specific query patterns.
  2. Sharded relational databases:
     • Horizontal partitioning by a chosen key (e.g., geographic chunk).
     • Route queries to relevant shard(s); use master/slave replication per shard for redundancy.
• Practical strategy:
  • Partition/shard by geographic chunk.
  • Retrieve nearby users from relevant shard(s) and then filter by age/gender/preferences.
  • Update user location periodically (e.g., hourly) from the client.
• Keep the recommendation engine as its own service that queries the sharded/replicated data stores.

Operational / reliability considerations

• Session management and persistent connections must scale horizontally; track connection-to-user mapping in a central sessions service.
• Avoid single points of failure: use replication (master/slave or multi-replica) and automated replacement of failed nodes.
• Use CDN + distributed object store for static assets.
• Balance trade-offs: complexity of a distributed DB vs. sharding complexity on RDBMS; explain the operational consequences and recovery strategies.

Interview & practical tips

• Start with features, clarify assumptions (active users, images per profile), and limit scope.
• Focus on how to scale and reason about trade-offs rather than exhaustive implementation details.
• Be prepared to discuss:
  • Protocols (HTTP vs WebSocket/XMPP)
  • Session/gateway patterns
  • Sharding and consistent hashing
  • NoSQL vs RDBMS trade-offs
  • CDN and static-asset strategies

Key components / terms (quick list)

• Gateway
• Profile service
• Image service
• Sessions service
• Matcher / Matches service
• Recommendation service
• Distributed file system / object store (S3-like)
• CDN
• Token-based auth
• WebSocket / XMPP / TCP for persistent connections
• Blob vs file storage debate
• Vertical partitioning, sharding (horizontal partitioning), consistent hashing
• Master-slave replication, NoSQL (Cassandra, Dynamo)

Speaker / source

Presenter / YouTube lecture: “System Design: TINDER as a microservice architecture” (video-based walkthrough; unnamed presenter in subtitles). The summary follows the presenter’s lecture-style recommendations.