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. The card is the product: each profile carries several photos plus short bio text, and the deck should feel infinite even though it is paged in batches. Interviewers want to hear how you keep the next card fully rendered before the current one leaves the screen.
- Swipe left/right gestures, tap buttons. Left is pass, right is like; the tap buttons must produce the exact same swipe event as a drag so the two input paths never diverge. Expect a follow-up on undo/rewind, which most apps ship as a paid feature.
- Real-time match notification when both users swipe right. The match is only knowable server-side, where the second right-swipe completes the pair, so the client learns about it through a push rather than by polling. Interviewers probe the latency budget — the celebratory modal should fire within about a second of the mutual like.
- Chat with matches. Messaging unlocks only after a match exists, so every thread is keyed to a match record; there is no way to message a profile you have not matched with, which shapes both the data model and the abuse surface.
- Profile editing, location-based matchmaking. Profile edits fan out to the ranking index so a changed photo or bio shows up in others’ decks; location narrows the candidate pool to a radius. Be ready to discuss stale location updates and privacy — most designs store coarse coordinates and never expose exact position.
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. Serving a full-resolution image to a phone screen wastes bandwidth and decode time and is indistinguishable at card size; pick the variant from the device’s screen density and step down further on cellular.
- Stop background prefetch when battery low. Prefetching five cards ahead is a real battery and data cost, so when the OS reports low-power mode, shrink the prefetch window to just the next card.
- Disable autoplay videos in profile until tap. Autoplaying every card’s video drains battery and burns the data cap fast; show a poster frame and start playback only on an explicit 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.
Keep sharpening your system design:
