The Tinder swipe deck is a fascinating UX-engineering challenge. Cards must be prefetched so swiping never hits a network spinner. Gestures must feel buttery. Matches must be detected within a second. The interview question tests both client-side animation/UX skill and the matchmaking pipeline behind it.
Functional requirements
- Browse a deck of profile cards with photos and bio
- Swipe left/right gestures, tap buttons
- Real-time match notification when both users swipe right
- Chat with matches
- Profile editing, location-based matchmaking
Architecture
The hot path is the deck — load cards quickly, decide swipes, sync to server. Match detection is a server-side pubsub.
Deck prefetch
Server returns batches of 10 cards ranked for the user. As the user swipes through, when 3 cards remain the client requests the next batch. Each card includes pre-signed CDN URLs for photos at appropriate resolutions.
Photos for the next 5 cards are prefetched eagerly. The currently-visible card has its full-resolution photo loaded; cards beyond that get a low-res progressive preview.
Gesture handling
Use the platform’s gesture recognizer. The card view follows the user’s touch with a slight rotation. Above a threshold (typically 100pt), it animates off-screen on release. Below, it springs back.
Animations run on the platform’s rendering thread (Core Animation on iOS, RenderThread on Android) — don’t do work on the main thread during swipe.
Swipe sync
Each swipe is a POST to /swipes with idempotency key. Client doesn’t wait for response — fire-and-forget with a queue for retries on failure. Server returns a “match” event if the swipe creates a mutual right-swipe.
Match notification
Server pushes a match event via WebSocket or push notification. Client shows a celebratory match modal. Match record is created server-side; chat is enabled.
Offline behavior
Swipes can be queued offline and uploaded later. Match detection requires both swipes — offline swipes get matched only after the upload completes.
Matchmaking ranking
Server-side. Combines location proximity, recently-active users, swipe history (Elo-style), demographic preferences. The client just renders.
Battery and data
- Cap photo resolution to ~720p for typical phones
- Stop background prefetch when battery low
- Disable autoplay videos in profile until tap
Frequently Asked Questions
What happens when the user swipes through 100s of cards quickly?
Client batches swipe events; flushes to server every few seconds. Animation never blocks on network. The server processes swipes in order received.
How do you prevent stale matches?
Each swipe has a TTL. If user A swiped right 6 months ago and user B finally swipes right today, the original swipe may have expired — at which point only a fresh swipe creates a match.
How is rate-limiting (free vs paid) enforced?
Server-side. Each swipe checks a counter. Free users get N swipes per day; paid users get unlimited. Client just shows a paywall when 429 returns.