Technologies referenced in this case study: Elasticsearch · Redis · Cassandra · DynamoDB · Apache Kafka

Related case studies: Maps & Geospatial · News Feed · Notification System · Chat Messaging · Leaderboard

How to Use This Case Study#

Organized for interview use first, reference second. Read front-to-back once, then return to the sections you are weakest on.

Naive design (query-on-open, swipe table keyed by swiper):
t=0:       21:00 local, evening peak. 3× baseline app opens in one metro.
t=+20s:    Every app open runs a geo query + 12 filters + ML rank against one geo shard.
t=+60s:    The Manhattan shard is at 95% CPU; Montana shard is at 4%.
t=+2min:   Deck latency p99 goes 250ms → 4s. Clients retry. Load doubles.
t=+5min:   Two users swipe right on each other within 40ms. Both "is there a reverse like?"
           reads miss the other's in-flight write. No match is created. Nobody ever knows.
t=+1hr:    A blocked user reappears in a deck because the deck cache predates the block.
           Trust & Safety ticket. This one is the incident that gets escalated to a VP.

Staff design (precomputed decks, pair-keyed swipes, density-balanced geo shards):
t=0:       Same peak.
t=+20s:    Decks served from a per-user precomputed list (Redis), ~5ms. Geo query runs
           asynchronously when the deck drops below 20 cards.
t=+60s:    Geo shards are balanced by *active user count*, not by area. No hot shard.
t=+5min:   Simultaneous swipes land on the same pair-keyed row. A conditional write
           creates exactly one match. Both users get the "It's a Match" screen.
t=+1hr:    Block events invalidate decks synchronously and a final safety filter runs
           at serve time. The blocked user never appears. A metric, not a ticket.

Executive Summary

If you only read one section, read this. Everything else in the case study elaborates on the contrast and the positions below.

What This Interview Actually Tests#

Tinder is not a geo-query question. Every candidate knows geohashes.

It is a two-sided marketplace with a write-heavy, correctness-sensitive edge (the swipe) and a read-heavy, freshness-tolerant edge (the deck) — and the design is about keeping those two edges from contaminating each other. It tests:

• Whether you notice that swipes outnumber deck fetches ~20:1 and outnumber matches ~50:1, so the write path — not the geo query — sizes the system
• Whether you catch the simultaneous-swipe race that silently loses matches
• Whether you treat safety filters (blocks, reports, bans) as fail-closed while treating everything else as fail-open
• Whether you see that ranking is a policy decision about who gets attention, owned by someone who is not the infrastructure team

The key insight: The deck can be minutes stale and nobody notices. A lost match or a blocked user reappearing is noticed by exactly the person you most need to keep. Staff engineers spend their consistency budget on the swipe → match edge and the safety edge, and spend nothing on the deck.

The L5 vs L6 vs L7 Contrast — Start Here#

The Staff Positions#

The Three Intents#

Three intents hide inside "design Tinder." Each leads to a different system.

🎯 Staff Move: "I'll design the discovery deck plus mutual matching, because that is Tinder's core loop and it forces the interesting split: a freshness-tolerant read path and an exactness-required write path. Live proximity is a different product with a different privacy posture — I'd scope it out explicitly rather than let it leak location precision into the deck design."

The Five Fault Lines#

In the Wild: Real Production Systems#

Why this section belongs here: citing publicly documented systems shows you've studied operational reality, not a whiteboard idealization.

Tinder — Geosharded Recommendations on Elasticsearch#

Tinder's engineering blog has described moving its recommendation candidate search to a geosharded Elasticsearch layout: the world is partitioned using Google's S2 cells, and cells are grouped into shards so that each shard carries a comparable load rather than a comparable area. A user's query hits only the shard(s) covering their search radius instead of scattering to every shard. Tinder has also publicly said that its early "Elo score" desirability ranking is no longer how it ranks.

Staff insight: The lesson isn't "use Elasticsearch." It's that the shard key is geographic but the shard boundary is chosen by load. Say that sentence in the interview and you've skipped ten minutes of geohash discussion.

Hinge — Stable-Matching-Inspired Recommendations#

Hinge has publicly said its "Most Compatible" feature draws on the Gale–Shapley stable matching algorithm: instead of showing everyone the most-liked profiles, it considers both sides' likely preferences to suggest pairs likely to be mutual. This is an explicit two-sided optimization rather than one-sided engagement ranking.

Staff insight: Dating is a two-sided market. Ranking only by "will A swipe right on B" ignores "will B swipe right on A," which is where the mutual-match rate — the actual product outcome — comes from. Naming this is an L6 ranking signal.

Uber H3 and Redis GEO — The Index Is a Commodity#

Uber open-sourced H3, a hexagonal hierarchical grid, for density and pricing; Redis ships GEOADD/GEOSEARCH, which store points as 52-bit geohash scores in a sorted set. Both are off-the-shelf.

Staff insight: When the spatial index is a library call, designing one from scratch in an interview signals misallocated time. Say "S2 or H3 for the cell ID, a sorted set or BKD tree for the lookup — now let's talk about the swipe path."

What Interviewers Probe#

System Architecture Overview#

Reading the diagram: Two synchronous paths and one asynchronous brain. The deck path pops cards from a precomputed Redis list and passes every card through the fail-closed safety filter. The swipe path does exactly one correctness-critical thing — the pair-keyed conditional write — and hands everything else to Kafka. The candidate generator is the only component that touches the geo index, and it runs off the critical path when a user's deck drops below its low-water mark. match.lost_pairs_total is the metric that catches the silent failure.

Quick-Reference: The 30-Second Cheat Sheet#

Key Numbers Worth Memorizing#

Interview Walkthrough

The most common mistake: candidates spend 20 minutes on geohash math and quadtree splitting, then run out of time before the swipe race, the safety tier, or the marketplace question. The phases below compress the geo index to about two minutes so the remaining 30+ go to the parts that decide your level.

Phase 1: Requirements & Framing (2–3 min)#

State the functional core in one breath:

"Users set a location, age range, gender preference and max distance. They see a deck of nearby profiles, swipe left or right, and when two people both swipe right, they match and can chat."

Then spend the remaining time on the non-functionals — that is where the design lives:

"Before I draw anything, let me get the ratios. I'll assume ~20M daily actives, ~80 swipes per active per day — that's ~1.6B swipes/day, roughly 18K/s average and ~55K/s at the evening peak. If a deck fetch returns ~50 cards, deck fetches are ~20× fewer than swipes. And if ~2% of right swipes are mutual, matches are ~1–2K/s at peak. So: swipes size the write path, decks are cacheable, and matches are rare but must be exact."

Commit to an intent and a consistency split:

"I'll design the discovery deck plus mutual matching. The deck can be minutes stale. The match must be exactly-once per pair. Safety — blocks and reports — is fail-closed and strongly consistent. Those three consistency tiers drive everything."

🎯 Staff Move: Say the ratios out loud before drawing. The interviewer learns in 30 seconds that you size from the workload, not from the feature list — and you have just justified why you won't spend time on the geo index.

Phase 2: Core Entities & API (1–2 min)#

Name the nouns and move on:

• Profile: user_id, prefs (age range, genders, max_distance_km), geo_cell (S2 level 13), last_active_at
• Deck: ordered list of candidate_id per user, generated_at, generated_cell
• PairState: key min(a,b):max(a,b), a_to_b ∈ {none, like, pass}, b_to_a, matched_at, version
• Match: match_id = hash(pair_key), both user IDs, created_at, chat_id
• SafetyEdge: (blocker, blocked), reason, created_at — never expires by default

GET  /v1/deck?limit=20                      → [{candidate_id, display_distance_mi, photos[], ...}]
POST /v1/swipes   {target_id, direction, client_swipe_id}
                                            → {matched: bool, match_id?}
POST /v1/location {lat, lng, accuracy_m}    → 204   (server snaps to cell; never echoes coordinates)
POST /v1/blocks   {target_id, reason}       → 204   (synchronous, fail-closed)
GET  /v1/matches?cursor=...                 → [{match_id, user, chat_id, created_at}]

🎯 Staff Move: "client_swipe_id makes the swipe idempotent — mobile networks retry, and I don't want a retry to double-count a like for ranking features or send a second match notification. And the location endpoint never returns coordinates — only a rounded display distance ever leaves the server."

Phase 3: High-Level Architecture (≤ 5 min)#

Staff candidates spend under five minutes here. Draw two paths and a brain:

Walk it in three sentences:

"The deck path pops from a precomputed list and runs a fail-closed safety check per card. The swipe path does one conditional write on a pair-keyed row, returns matched: true if this write completed the pair, and emits an event. Everything expensive — geo query, ranking, notifications — is asynchronous and driven by the event log."

Phase 4: Transition to Depth#

The sentence that steers the interviewer to where you are strongest:

"The geo index is a solved problem — S2 cells, sharded by load. I think the three interesting parts are the simultaneous-swipe race, keeping safety fail-closed while decks are precomputed, and hot geo shards at peak. Which would you like first? If you don't mind, I'll start with the swipe race because it's the one that silently loses data."

🎯 Staff Move: Offering a menu with a recommendation is the Staff pattern. It shows you know where the bodies are buried and still lets the interviewer steer.

Phase 5: Deep Dives (25–30 min)#

Budget your deep-dive time across these, in the order the interviewer allows:

Match race, as you'd say it:

"If A→B and B→A are stored in separate partitions keyed by swiper, each swipe does write-own then read-other, and under eventual consistency both reads can miss. Instead, both directions live in one row keyed min:max. A's swipe is UPDATE pair SET a_to_b='like' IF version=v. If the row now shows both likes and matched_at is null, the same conditional write sets matched_at. Exactly one writer wins that condition. The loser retries, reads the row, sees the match already exists, and returns matched: true too — both users get the screen, one match row exists."

Phase 6: Wrap-Up (2–3 min)#

Close with constraints, evolution, and what you deliberately did not build:

"To summarize: swipes size the system and go through a pair-keyed conditional write; decks are precomputed and eventually consistent; safety is a separate fail-closed tier. What I'd monitor first is match.lost_pairs_total from the reconciliation job and geo shard load skew. What I'd build next is two-sided ranking with impression caps, because that's the lever on mutual-match rate. What I skipped: live proximity, which has a different privacy posture and I'd want a separate review for it."

Common Timing Mistakes#

1. The Staff Lens#

1.1 Why This Problem Exists in Staff Interviews#

Proximity matching is a disguise test. The prompt names a geographic feature, and the geographic part is the easiest thing in the system. Interviewers pick it because it lets them watch whether you follow the prompt's framing or the workload's shape.

The workload has three edges with incompatible requirements:

A Senior engineer who designs all three at the same consistency level either over-pays on decks (strongly consistent geo queries on every open) or under-pays on safety (eventually consistent block lists). Staff engineers make the split explicit and name who pays for each.

1.2 The L5 vs L6 Contrast — Visual#

1.3 The Staff Question That Cuts Through Everything#

"Which mistake would a user notice, and which would they never know about?"

Every decision in this system falls out of that question:

• A card that is 10 minutes stale — never noticed. Cache it.
• A profile shown twice — noticed, mildly annoying. Bloom filter; accept ~1% false positives (which hide a card, never re-show one).
• A lost match — never noticed by the users, but it is the product's core outcome silently failing. Make it structurally impossible and measure it anyway.
• A blocked user reappearing — noticed immediately, by the person most harmed. Fail-closed, synchronous, audited.

🎯 Staff Move: "The failure I worry about most is the one no user will ever report: two people who liked each other and never matched. I'm going to design that out structurally and then count it with a reconciliation job, because it will never show up in support tickets."

2. Problem Framing & Intent#

2.1 The Three Intents — Explained#

Intent 1 — Discovery deck. The user wants a stream of plausible, nearby, not-yet-seen people. The system's job is candidate generation (geo + preferences + exclusions) and ranking. Latency matters at the moment of the swipe animation (the next card must already be on the device); freshness matters on the order of minutes. The deck is a recommendation feed with a geographic filter — structurally closer to News Feed than to Maps & Geospatial.

Intent 2 — Mutual matching. The user expresses interest; the system must detect mutual interest exactly once and trigger the match moment (notification, chat creation). This is a contention problem on a two-party key — the same family as seat reservation in Flash Sales & Ticketing, where two writers race for one logical resource. See Dealing with Contention.

Intent 3 — Live proximity. "Who is within 500 m right now" or "whom did I cross paths with today" (Happn's model). Requires continuous location updates, second-level freshness, and a much stricter privacy posture because it reveals current location. This is closer to the driver-location problem in Ride Hailing & Delivery.

2.2 When NOT to Use Proximity Matching#

🎯 Staff Move: "At under a few million users per metro I would not geo-shard at all — PostGIS with a GiST index on one primary handles this. Geo-sharding is a scaling tool, and it brings a shard map that someone has to own. I'd adopt it when a single region's index stops fitting in memory or its write rate exceeds one primary."

2.3 What the Interviewer Leaves Underspecified#

2.4 Precise Terminology#

3. The Fault Lines#

Five structural tensions. For each: the options, who pays, the Staff default, and when to deviate.

3.1 Fault Line 1: Precompute vs Query-on-Open#

The Staff default: on-demand precompute. The deck holds ~150 IDs; when it drops below ~20, the Deck Service emits a deck.refill event; the Candidate Generator runs geo → preference → exclusion → rank and writes a new list. Invalidation triggers, owned and documented:

When to deviate: at < 1M DAU, query-on-open against a single PostGIS or Elasticsearch cluster is simpler and cheap enough. Precompute buys latency and peak-load isolation; it costs a trigger list someone must own.

🎯 Staff Move: "Precompute is only safe if the invalidation triggers are a documented contract. The dangerous one is block — that can't wait for a refill. So block does a synchronous purge plus a serve-time filter; everything else rides the low-water mark."

3.2 Fault Line 2: Swipe Keying — Swiper vs Pair#

This is the fault line that separates levels most sharply.

The Staff default: pair-keyed conditional write as the source of truth for matching; a swiper-keyed history table populated asynchronously from Kafka for "my swipes," undo, and analytics.

# Swipe handler (pair store supports compare-and-set on a version)
pair = key(min(a,b), max(a,b))
loop up to 3 times:
    row = read(pair)                          # consistent read on the owning partition
    if row.dir(swiper) == direction: return idempotent_ok(row)   # retry of same swipe
    new = row.with(dir(swiper) = direction)
    if new.a_to_b == LIKE and new.b_to_a == LIKE and row.matched_at is null:
        new.matched_at = now(); new.match_id = hash(pair)
    if cas(pair, expected=row.version, new): 
        emit(swipe_event); if new.matched_at and not row.matched_at: emit(match_event)
        return {matched: new.matched_at != null, match_id: new.match_id}
# fall through → 503, client retries with same client_swipe_id

The contention on a single pair row is effectively two writers, so CAS conflict rates are tiny — this is the regime where optimistic concurrency shines (well under ~5% conflict). Cassandra LWT costs ~4 round trips (Paxos) — acceptable only because it is per-swipe on a small row; DynamoDB conditional writes cost one round trip and are the cheaper fit.

When to deviate: if your store has no conditional writes and you can't route by pair, use quorum reads and make match creation idempotent on match_id = hash(pair). You trade silent loss for harmless duplicates that collapse on the idempotency key.

🎯 Staff Move: "Keying by swiper feels natural because that's how the UI thinks. Keying by pair is how the invariant thinks. I key the source of truth by the invariant and derive the UI view from the log."

3.3 Fault Line 3: Location Precision vs Privacy#

Precise-distance leakage in location-based dating apps is a well-publicized class of vulnerability — security researchers have repeatedly demonstrated trilateration against apps that returned precise or finely rounded distances. The fix is structural: the server should not know more precision than it needs, and the API should never compute on more precision than it reveals.

The Staff default: client sends lat/lng; the Location Service snaps to an S2 level-13 cell (~0.8 km²) and stores only the cell; displayed distances are computed between cell centers and rounded to whole miles/km with a floor of "< 1 mile"; raw coordinates are discarded within seconds and never logged.

When to deviate: live-proximity features need ~100 m. Scope them as a separate, opt-in product with its own privacy review, short retention (minutes), and no distance display.

🎯 Staff Move: "Privacy here isn't a policy page, it's a data-minimization decision in the Location Service. If we never store more than a 1 km cell, no bug, insider, or subpoena can reveal more than that."

3.4 Fault Line 4: Engagement Ranking vs Marketplace Health#

The Staff default: score = P(viewer→cand) × P(cand→viewer) with a per-profile impression cap per 24 h (e.g., a profile appears in at most ~N decks where N scales with the local active population), and an exploration budget (~5–10% of deck slots for new or low-exposure profiles).

The owner question is the Staff-level signal: the ranking objective is a product decision with marketplace consequences. Infrastructure implements it; a named product owner signs off on objective changes, and every change ships behind an A/B test with mutual-match rate and like-distribution Gini as guardrail metrics.

When to deviate: early-stage apps with small populations should rank by distance and recency — there isn't enough data to train two-sided models, and exploration is the whole deck.

🎯 Staff Move: "Optimizing for right-swipes and optimizing for matches are different objectives. I'd rank for mutual probability and put a guardrail metric on how concentrated likes become. Whoever owns the ranking objective owns that guardrail."

3.5 Fault Line 5: Area-Based vs Load-Based Geo Sharding#

The Staff default: compute the S2 level-13 cell for each user; walk cells in Hilbert order and cut shard boundaries every ~K active users (weighted by query load, not just population). Store the map as a versioned config. A query computes the cells covering its radius (an S2 RegionCoverer call), maps them to shards — typically 1–3 — and queries those in parallel.

Rebalancing: when a shard's p99 or doc count exceeds ~1.5× the median for 7 days, split it; reindex the moving range into the new shard, dual-read during migration, flip the map version. The map version must be in every query log so you can debug "why did this user see nobody?"

When to deviate: under a few million users, one cluster with a geo_point field and no geo-sharding. Geo-sharding is justified when fan-out cost or shard size forces it.

🎯 Staff Move: "The shard key is geography; the shard boundary is load. And the shard map is a production artifact — versioned, owned, and in every query log — not a constant in the code."

4. Failure Modes & Operational Reality#

4.1 The Silent Lost Match#

Scenario: the pair store is eventually consistent and match detection does write-then-read-reverse keyed by swiper.

t=0        Evening peak, 55K swipes/s. Store replica lag p99 = 80 ms (normally 5 ms)
           because a compaction storm is running on 2 of 12 nodes.
t=+1min    Pairs that swipe on each other within the lag window: both reverse reads miss.
t=+10min   ~0.4% of mutual pairs lost. No errors. No alerts. Match rate dashboard
           dips 0.4% — inside normal daily variance.
t=+3 days  A data scientist notices mutual-like-without-match rows in the warehouse.
t=+3 days  Nobody can notify the lost pairs retroactively without it being creepy.

• Detection: match.lost_pairs_total from a reconciliation job that scans pair rows (or joins swipe history) for mutual-like without matched_at. Alert: > 0 for 15 min → page.
• Blast radius: a fraction of new matches during the lag window; invisible to users.
• Mitigation: switch to pair-keyed conditional writes; reconciliation job creates missed matches within minutes (acceptable UX: "You have a new match").
• Prevention: make the invariant structural (Section 3.2), then keep the reconciliation job as a canary.
• Owner: Matching platform team.

4.2 The Hot Geo Shard#

t=0        New Year's Eve, 23:30 local, one metro. App opens 6× baseline.
t=+30s     Deck refills cluster: every user who swiped through their deck triggers a
           candidate generation against the same 2 shards.
t=+2min    Shard CPU 98%; candidate generation p99 300 ms → 6 s. Refill queue grows.
t=+4min    Decks run dry. Clients show "There's no one new around you."
t=+6min    Users widen distance to 160 km → queries now cover 3–4 shards each. Worse.

• Detection: geo.shard_cpu_skew (max/median > 3), recs.refill_queue_depth, deck.empty_responses_total.
• Blast radius: one metro, all users in it — and the metros sharing its shards.
• Mitigation: serve stale decks (skip generated_at expiry during overload); cap refill concurrency per shard; extend deck size to 300 on refill to cut refill frequency; drop to distance-only ranking to shed ML cost.
• Prevention: load-balanced shard map; scheduled pre-scaling for known events (NYE, festivals); replicas of hot shards for read fan-out.
• Owner: Recommendations (refill policy) + Search platform (shard map, replicas).

4.3 Blocked User Reappears#

t=0        Alice blocks Bob at 20:00.
t=+0s      Block written to safety store. Bob removed from Alice's *current* deck.
t=+10min   Alice's deck is regenerated by a candidate generator replica that read a
           cached copy of the safety set loaded at 19:50.
t=+12min   Bob appears in Alice's deck. Alice reports the app for harassment.

• Detection: safety.serve_filter_hits_total (serve-time filter catching an ID that the generator should have excluded — should be ~0; non-zero means an upstream cache is stale), plus user reports tagged "blocked user reappeared."
• Blast radius: one user — but the most harmful one-user incident the product has.
• Mitigation: serve-time filter against the authoritative safety store on every card (batch lookup of ~20 IDs, ~2 ms); fail-closed: if the safety store is unreachable, return an empty deck with a retry hint.
• Prevention: safety set is never cached by candidate generators beyond a version check; every surface that renders a person calls the same filter (deck, likes-you, matches, notifications).
• Owner: Trust & Safety platform.

4.4 The Celebrity Swipee (Hot Key)#

A creator with a large following joins; they receive ~500K right swipes in an hour.

• What breaks: anything keyed by swipee — a "likes you" counter, a reverse index for "who liked me" — becomes a hot partition (~140 writes/s on one key sustained, bursts of thousands). Pair-keyed storage is unaffected because each pair is a separate row.
• Detection: store.partition_write_rate_max, likes_you.counter_contention.
• Mitigation: sharded counters (likes_you:{user}:{0..15}), summed on read; cap the displayed count ("99+"); the "likes you" grid reads from a sampled list, not the full set.
• Prevention: impression caps mean a celebrity profile is shown to a bounded number of people per window — fixing the marketplace problem also fixes the hot key.
• Owner: Matching platform (storage), Recommendations (caps).

4.5 The Deck Refill Thundering Herd#

After a Redis failover, all deck lists are gone. Every active user's next request triggers a refill.

t=0        Redis primary for deck lists fails; replica promoted but with a
           replication gap of 90 s (async replication).
t=+5s      ~15% of decks empty. 300K refills enqueued in 30 s.
t=+1min    Candidate generation at 10× normal; geo index saturates.

• Detection: deck.cache_miss_rate > 10%, recs.refill_rate spike.
• Mitigation: singleflight per user; refill admission control (token bucket per shard); serve a cheap fallback deck (distance-sorted, no ML, capped at 20 cards) while the full refill queues.
• Prevention: the fallback deck path is tested monthly in a game day; deck store is treated as a cache — losing it degrades quality, never availability.
• Owner: Recommendations.

4.6 Location Spoofing and Bot Swarms#

Bots spoof GPS into dense metros and swipe right on everyone to harvest matches for scams.

• Detection: swipe.right_ratio per account > 95% over > 200 swipes; impossible travel (> 900 km/h between location updates); device attestation failures.
• Mitigation: rate-limit right swipes per account (a product cap also serves as abuse protection — see Rate Limiting); shadow-ban: accept swipes but exclude from others' decks.
• Owner: Trust & Safety, with the rate-limit policy owned by the API platform.

4.7 Operational Reality Matrix#

🎯 Staff Move: "Look at the mitigation column: ranking fails open, the deck store fails to a cheap fallback, but safety fails closed. The system has three different degraded modes on purpose — and each has a named owner who agreed to it."

5. Evaluation Rubric#

5.1 Level-Based Signals#

5.2 Strong Hire Signals#

5.3 Lean No-Hire Signals#

5.4 Common False Positives#

• Deep S2/H3 knowledge ≠ proximity-matching design. Knowing Hilbert curves is nice; knowing where to put the shard boundary is the signal.
• ML ranking vocabulary ≠ marketplace thinking. "Two-tower model with embeddings" without "who gets zero likes" misses the Staff point.
• "Eventually consistent" everywhere ≠ understanding consistency. The signal is choosing different tiers per edge.
• Drawing Kafka ≠ async design. The question is what stays synchronous (the CAS) and why.

6. Interview Flow & Pivots#

6.1 Typical 45-Minute Shape#

6.2 How Interviewers Pivot — And What They're Testing#

6.3 What to Deliberately Skip#

6.4 Follow-Up Questions to Expect#

1. "What happens if both users swipe at exactly the same millisecond?"
2. "A user swipes through 200 cards in 3 minutes. What's the load on your system?"
3. "How do you avoid showing someone a person they already swiped left on six months ago?"
4. "How much storage do swipes take after a year, and what do you delete?"
5. "The ranking service is down. What does the user see?"
6. "A user blocks someone. Walk me through every surface that has to change."
7. "How do you rebalance a geo shard without downtime?"

7. Active Drills#

Drill 1: The Opening#

Prompt: "Design Tinder. You have 45 minutes."

Drill 2: The Core Mechanic — Simultaneous Swipes#

Prompt: "Alice and Bob swipe right on each other within 10 ms. Walk me through it."

Drill 3: Make It Concrete — Storage Growth#

Prompt: "How big is the swipe data after a year, and what do you keep?"

Drill 4: Dependency Down — Ranking Service Outage#

Prompt: "The ranking model service is returning 500s. What happens?"

Drill 5: Hot Key — The Celebrity#

Prompt: "A celebrity joins and gets 2 million right swipes in a day."

Drill 6: Multi-Tenant — Multiple Apps on One Platform#

Prompt: "The company runs three dating apps. Should they share infrastructure?"

Drill 7: Build vs Buy — The Geo Index#

Prompt: "Would you build a custom geo index?"

Drill 8: Policy Change Without an Outage — New Ranking Objective#

Prompt: "Product wants to switch ranking from right-swipe probability to mutual probability. Ship it."

Drill 9: Cost#

Prompt: "Finance says infra cost per DAU doubled this year. Where do you look?"

Drill 10: Multi-Region#

Prompt: "Expand from the US to the EU and India."

8. Deep Dive Scenarios#

Deep Dive 1: Saturday Night Peak — Empty Decks in One Metro#

Context: Saturday, 22:00 local. Users in one large metro report "There's no one new around you." Global dashboards look green. The on-call escalates to you.

Questions to Surface First:

• Is this one metro or several? Do the affected metros share geo shards?
• Are decks empty because candidate generation is slow, or because it returns zero results?
• Did anything change today — shard map version, ranking model, a filter?
• Is the refill queue growing, and is it per-shard or global?

Typical L5 Approach: Checks the Deck Service error rate (zero — it is returning empty lists successfully), scales the Deck Service, then scales the Elasticsearch cluster uniformly. Adds capacity to shards that are idle while the hot one stays hot.

Staff Approach: Goes straight to per-shard skew: geo.shard_cpu_skew and recs.refill_queue_depth{shard}. Confirms the affected metro maps to 1–2 shards at 95%+ CPU. Enables the pre-built overload mode: serve stale decks past their 6 h expiry, cap refill concurrency on the hot shards, switch refills there to distance-only ranking, and double refill size to 300. Then adds read replicas to the hot shards only.

Principal Approach: Asks why a predictable weekly peak can page anyone. Makes shard capacity a function of the weekly load curve per metro, with scheduled replica scaling owned by the Search platform, and adds "metro peak headroom ≥ 40%" to the quarterly capacity review. Pushes Recommendations and Search to agree on a single overload contract (what degrades first) so the next incident is a runbook step, not a debate.

Key Takeaway: "An empty deck is an availability incident even when every service returns 200. Measure empty responses, not errors."

What clears the Staff bar:

• Looks at per-shard skew before global capacity
• Has a pre-agreed degrade ladder
• Converts a recurring peak into scheduled capacity

Deep Dive 2: The Silent Failure — Match Rate Down 3%#

Context: The weekly business review shows mutual-match rate down 3% week over week. No incidents were declared. The VP of Product asks engineering whether something is broken.

Questions to Surface First:

• Did right-swipe volume change, or did mutual detection change?
• Is match.lost_pairs_total non-zero? When did the reconciliation job last run successfully?
• Any ranking, shard map, or store changes in the window?
• Is the drop uniform across metros and platforms (iOS vs Android)?

Typical L5 Approach: Checks error rates on the Swipe and Match services — all normal. Suggests it's seasonal or a ranking effect and hands it to data science.

Staff Approach: Separates correctness from policy. First, correctness: queries pair rows with both likes and no matched_at — finds 1.1% of mutual pairs unmatched since a store upgrade 9 days ago that changed the default read consistency on one client library from LOCAL_QUORUM to ONE, and the reconciliation job had been silently failing on a permissions change. Then policy: the remaining ~2% is a ranking experiment that shifted exposure. Two causes, two owners.

Principal Approach: Treats the reconciliation job failing silently as the real incident. Requires every correctness canary to have a heartbeat alert ("job has not reported in 2 h") and makes consistency level an enforced, reviewed setting in the shared client library — not a per-call default. Adds "lost match rate" to the weekly business review so it is a number executives see, not one engineers discover.

Key Takeaway: "The silent failure in this system is a missing row. Only a job that looks for missing rows will ever find it — and that job needs its own alert."

What clears the Staff bar:

• Separates correctness regressions from policy/ranking effects
• Suspects the canary before trusting it
• Routes the customer-facing decision to product

Deep Dive 3: Large-Customer Onboarding — A University Campus Launch#

Context: Marketing is launching a campus program: 40 universities, ~800K new signups expected in 72 hours, heavily concentrated in small towns that currently map to low-traffic shards.

Questions to Surface First:

• Which shards cover these towns, and what's their current headroom?
• Are new users' decks cold-started (no ranking features) — what does candidate generation cost for them?
• Does the campus program have its own ranking rules (e.g., students-only filter)?
• What is the expected swipe rate per new user in the first session? (New users swipe 2–3× more.)

Typical L5 Approach: Scales the whole Elasticsearch cluster by 30% ahead of launch.

Staff Approach: Projects load per shard: small-town shards will go from ~10K to ~60K actives. Pre-splits those shards before launch using the shard map tooling, pre-warms the pair store partitions, and sets a cold-start deck path (distance + recency + exploration) that doesn't need ML features. Adds a campus filter as a tag on documents, not a separate index. Watches new-user swipe velocity against right-swipe caps to avoid bots riding the launch.

Principal Approach: Establishes a "launch readiness" process between Marketing and Platform: any campaign projecting > 5% regional growth files a capacity request 2 weeks ahead, with per-shard projections generated by a tool. Makes shard pre-splitting self-service for Recommendations so Platform isn't a bottleneck.

Key Takeaway: "Growth lands on shards, not clusters. Project per shard."

What clears the Staff bar:

• Per-shard projection instead of uniform scaling
• Cold-start path designed for new users
• Bot risk tied to a launch

Deep Dive 4: Post-Mortem — Blocked User Reappeared, Press Inquiry#

Context: A user posted on social media that a person she blocked appeared in her deck two days later. A journalist has asked for comment. You're leading the post-mortem.

Questions to Surface First:

• Which surface showed the blocked person — deck, likes-you grid, or a push notification?
• Was the block recorded in the safety store? When?
• Did the blocked person create a new account (ban evasion) or is it the same account?
• Is the serve-time safety filter on that surface?

Typical L5 Approach: Finds the bug — the "likes you" grid was built by a different team and read from a cache that didn't check the block list — and fixes that cache.

Staff Approach: Fixes the bug, then asks why a surface could render a person without calling the safety filter at all. Audits every surface that renders a person (7 found, 2 without the filter). Moves the filter into the shared "render a profile card" API so it cannot be bypassed. Adds safety.serve_filter_hits_total per surface. Separately investigates ban evasion: same device fingerprint, new account.

Principal Approach: Writes the Trust & Safety contract: every surface that shows a person MUST call the safety API; CI rejects services that fetch profile cards without it; quarterly audit. Funds a device-level identity signal for ban evasion. Coordinates the external response with Comms and Legal with an accurate technical timeline.

Key Takeaway: "A safety filter that each team must remember to call is a safety filter that will be skipped."

What clears the Staff bar:

• Generalizes from one bug to a class of surfaces
• Makes the correct path the only path
• Distinguishes bug from ban evasion

Deep Dive 5: Multi-Region Expansion — India Launch#

Context: The company launches in India. Data residency requirements and a very different density profile (extremely dense metros, mobile networks with high packet loss).

Questions to Surface First:

• What data must stay in-country? Profiles, swipes, messages, location?
• What are p99 RTTs from major Indian cities to the nearest current region? (~150–250 ms to Singapore is common.)
• Is cross-border matching (travel mode) allowed?
• What's the expected density — how many actives per S2 level-13 cell in Mumbai vs current top metros?

Typical L5 Approach: Deploys a copy of the stack in an Indian cloud region.

Staff Approach: Deploys a regional cell with its own geo shards, pair store and deck store; safety graph replicated globally (bans follow a person). Recalibrates the shard map for density (Mumbai cells may need level 14–15 granularity). Client-side: larger deck prefetch (40 cards) and swipe batching (send up to 10 swipes per request) for lossy networks, with client_swipe_id idempotency making retries safe. Travel-mode swipes route to the swipee's home region.

Principal Approach: Treats the region as a template: "region-in-a-box" with a residency checklist, a shard map generator, and a launch runbook — so the next 5 regions cost weeks, not quarters. Makes a portfolio decision about which global services (identity, safety, payments) must become multi-region before more launches.

Key Takeaway: "A fail-closed global dependency sets the availability ceiling for every region. Budget for it."

What clears the Staff bar:

• Regional vs global state separated explicitly
• Network-conditions-aware client design
• Notices fail-closed dependencies cap availability

9. Level Expectations Summary#

After studying this case study, you should be able to:

• Size the system from swipe:deck:match ratios and justify why the write path dominates
• Explain the simultaneous-swipe race and fix it with a pair-keyed conditional write
• Assign consistency tiers: deck eventual, pair exact, safety fail-closed
• Design load-balanced geo sharding with S2 cells and a versioned shard map
• Name the marketplace problem in ranking and propose impression caps and two-sided scoring
• Coarsen location to defeat trilateration
• Name the owner and metric for every failure mode
• At L7: price the system, define the safety contract across products, and plan the shard-map evolution

The Bar for This Question#

Mid-level (L4): Designs a geo query, a swipe table and a match check. Works in the demo. Doesn't estimate load, doesn't see the race, doesn't mention safety or privacy.

Senior (L5): Adds caching, sharding by geohash, Kafka for notifications, and reasonable storage estimates. Knows eventual consistency exists. Misses the pair-keyed invariant, treats all data at one consistency level, and ranks by ML score without thinking about who gets attention.

Staff+ (L6): Frames the three intents, sizes from ratios, builds exactly-once matching structurally, separates safety as fail-closed, shards geo by load, and names owners for ranking, safety and the shard map. Every failure has a metric. The interviewer should learn something from the answer.

10. Staff Insiders: Controversial Opinions#

10.1 "Tinder Is Not a Geo Problem"#

The Staff position: Spend 2 minutes on geo, 25 on swipes, safety and marketplace.

Why this matters in interviews: Interviewers who ask this prompt have usually seen 50 geohash walkthroughs. The candidate who reframes early stands out.

10.2 "Precise Location Is a Liability, Not a Feature"#

The Staff position: Store cells, not coordinates. Round everything that leaves the server.

Why this matters in interviews: Privacy by data minimization is a Staff-level signal; "we'll encrypt it" is not.

10.3 "Ranking for Engagement Kills Dating Apps"#

The Staff position: Rank for mutual probability with exposure caps; measure concentration.

Why this matters in interviews: It shows you think about the marketplace, not just the model.

10.4 "The Reconciliation Job Is More Important Than the Algorithm"#

The Staff position: Structural correctness plus an audited, alerting reconciliation job.

Why this matters in interviews: Staff engineers design for the day their design is subtly broken.

10.5 "Don't Geo-Shard Until It Hurts"#

The Staff position: One cluster until fan-out or size forces geo-sharding; then load-balanced S2 ranges.

Why this matters in interviews: Knowing when not to build is as strong a signal as knowing how.

11. The Principal Lens (L7)#

Why L7 Sees This Problem Differently#

A Staff engineer designs Tinder. A Principal engineer notices that the company doesn't run one proximity product — it runs a portfolio (dating apps, friend-finding, events, local marketplaces), and every one of them rebuilds the same four capabilities: a geo candidate index, a mutual-consent invariant, a safety graph and a notification fan-out. The L7 question is which of those are platforms with contracts and which are product differentiation, and what it costs — in dollars, headcount and trust incidents — to leave that line undrawn. The safety graph in particular is not an engineering nicety: it is the one capability where inconsistency between products becomes a public incident.

The Org-Level Fault Line#

One shared "people-nearby" platform vs per-product stacks.

🧭 Principal Move: "Centralize the things where divergence creates harm — safety and privacy — and the things that are pure commodity — geo and notifications. Leave ranking to products. The platform's contract is the safety API and the pair invariant; everything above that line is product."

Cost Model#

Assumptions: cloud list prices order-of-magnitude, ~80 swipes/DAU/day, RF 3, 180-day TTL on pass rows, precomputed decks, loaded engineer cost ~$250K/yr.

The line that changes the business case: at 10M+ DAU, pair-store writes and candidate recompute dominate. Every 2× increase in deck size roughly halves recompute; every TTL cut on pass rows reduces storage linearly. These two knobs are worth more than any index optimization.

The 3-Year Evolution Path#

One-Way Doors vs Two-Way Doors#

The Standard I'd Write#

RFC: People-Surface Safety & Proximity Data Standard (v1)

Scope: Every service that renders, recommends, notifies about, or stores the location of a person, across all apps.

Mandatory requirements:

• Services MUST fetch profile cards through the Profile Card API, which applies the safety filter. Direct profile-table reads for rendering are rejected in CI.
• The safety filter MUST fail closed. A surface that cannot reach the safety service MUST render nothing.
• Services MUST NOT store raw coordinates longer than 60 seconds. Persisted location MUST be an S2 cell at level ≤ 13 (or H3 resolution ≤ 8).
• APIs MUST NOT return coordinates of another user. Displayed distances MUST be rounded to ≥ 1 mile/km.
• Mutual-consent features MUST use the pair-invariant store and MUST have a reconciliation job with a heartbeat alert.
• Ranking objective changes SHOULD ship with exposure-concentration guardrail metrics.

Exceptions: Filed with the T&S platform and Privacy; time-boxed to 90 days; reviewed monthly.

Success metrics: 0 blocked-user exposures per quarter; match.lost_pairs_total = 0 for 30 consecutive days; 100% of people-rendering surfaces on the Profile Card API within 2 quarters.

What I'd Tell the VP#

"The part of this product that can hurt us most isn't the matching algorithm — it's whether a person someone blocked can ever reappear, and whether we hold location data we don't need. I want one safety and location standard across all our apps, owned by one platform team of about eight engineers. It costs roughly $2M a year in people and saves us duplicate infrastructure in each app. It also turns our worst-case headline into something we can prove doesn't happen. Ranking and product experience stay with each app team so they keep their speed."

Principal Interview Signals#

Staff answers that L7 interviewers find insufficient:

• "We'll add the safety filter to every surface." — Correct, but relies on every team remembering; L7 makes bypass impossible.
• "We'll shard by load with S2." — Correct, but doesn't address who owns the shard map across products or when reshards happen.
• "Ranking should be two-sided." — Correct, but doesn't say who approves objective changes or how the org measures marketplace health over years.

Appendices

Appendix A: Mechanics in Depth#

A.1 Candidate Generation Pipeline#

Preference filtering must be bidirectional: A's preferences must admit B, and B's preferences must admit A. A one-directional filter wastes deck slots on people who will never see A.

candidates = geo_index.search(
    cells   = s2_cover(user.cell, user.max_distance_km),
    filter  = age in user.age_range AND gender in user.genders
              AND user.age in cand.age_range AND user.gender in cand.genders
              AND last_active > now - 30d,
    size    = 1500)
candidates = [c for c in candidates if not seen_bloom.might_contain(c.id)]
candidates = safety.filter(user.id, candidates)          # authoritative, fail-closed
scored     = rank(user, candidates)                      # P(u→c) × P(c→u)
deck       = apply_caps_and_exploration(scored, n=150)
redis.del(deck_key); redis.rpush(deck_key, *deck); redis.expire(deck_key, 6h)

A.2 Why Bloom Filters Fit the Seen Set#

A false positive hides a candidate the user hasn't seen (harmless at ~1%). A false negative is impossible, so a seen candidate is never re-shown by the filter. At 10K swipes and 1% FPR: m ≈ 9.6 bits × 10K ≈ 12 KB, k = 7 hashes. Heavy swipers (100K lifetime) roll to a new filter per 6-month epoch, matching the pass-row TTL.

A.3 Distance Rounding#

display_km = max(1, round(haversine(cell_center(u), cell_center(c))))

Computed from cell centers, not raw coordinates, so no amount of repeated queries converges below the cell size.

Appendix B: Keys and Data Model#

Appendix C: Coordination Mechanisms — Quick Comparison#

Appendix D: API Contract and Client Behavior#

• POST /swipes carries client_swipe_id; retries within 24 h return the original result.
• Clients batch up to 10 swipes per request on poor networks; server processes in order per pair.
• Deck prefetch: request more when ≤ 5 cards remain locally; server refill is triggered at ≤ 20 server-side.
• On 503 from /swipes, clients retry with jittered exponential backoff (base 200 ms, cap 5 s) and keep swipes in a local queue for up to 5 minutes.
• /location accepted at most once per 5 minutes unless movement > 1 km; the server returns 204 and never echoes location.

Appendix E: Observability#

E.1 Core Metrics#

E.2 Critical Alerts#

E.3 Control Plane vs Data Plane#

Data plane: deck serve, swipe CAS, safety filter. Control plane: shard map, ranking config, caps, triggers. Control-plane changes are versioned, canaried by metro, and logged with the version in every data-plane log line.

Appendix F: Scale Evolution#

F.1 What You Don't Build on Day One#

• Custom spatial index
• Geo-sharding
• ML ranking (distance + recency + exploration is enough early)
• Multi-region active-active pair store
• Live proximity

What you do build on day one: the pair-keyed invariant, cell-only location storage, and the fail-closed safety filter. Those are the one-way doors.

Appendix G: Fairness, Multi-Tenancy and Cost#

• Exposure fairness: track the Gini coefficient of impressions and likes per metro weekly; guardrail on ranking changes.
• Exploration budget: 5–10% of deck slots for new or under-exposed profiles; new users get a time-boxed boost of ~48 h.
• Tenancy across apps: per-app index namespace, per-app caps, shared shard map, per-app quota on candidate generation to prevent one launch from starving others.
• Showback: cost per DAU and cost per match by app and component, reported monthly.