HLD-227·Caching & Consistency
Medium · 1,000 ptsGeo-Sharded Dating Deck & Mutual Swipe Matcher
Design Tinder / Bumble’s candidate recommendation deck and low-latency right-swipe mutual match detector across dense metropolitan geohash cells.
Max p99
≤ 55 ms
Availability
≥ 99.5%
Budget
≤ $5,650
Functional Requirements
- FR-1GET /deck/{user_id} — Fetches precomputed nearby candidate profile cards excluding already-swiped users.
- FR-2POST /swipes — Records left/right swipe and immediately detects mutual right-swipe matches.
- FR-3PATCH & DELETE /deck/{user_id} — Updates, cancels, or deletes user_id records and immediately invalidates or updates cached state (read-after-write).
- FR-4Must guarantee read-after-write mutual match detection and never resurface swiped profiles.
Workload Profile
Evening Baseline32,000 Deck Read RPS / 9,000 Swipe Write RPS
Sunday Night Peak86,000 Read RPS / 24,000 Swipe Write RPS
Active Working Set26 GB active swipe bitsets & candidate decks
Traffic DistributionDense geo skew in major metro user_id / cell_id shards
Consistency Model
Read-after-write consistency on swipe state so swiped cards do not reappear and mutual matches fire instantly.
Solutions Locked
Sign in and either achieve AC or complete 3 official submissions on this question to inspect community diagrams and writeups.
Loading solutions...
Submission History (0)Select to replay
No submissions yet
Click Submit in the top bar to evaluate against all 7 judge cases and save each run here.
Design Write-up
0 boxes · 0 edges
0 words