tinder

Match detection asks: "Did Bob already swipe right on Alice?" This is a per-pair question — checking the state of a specific relationship.

Pair Model (natural fit): The match state lives in one row. One point lookup answers "are they matched?"

Directed Model (requires reconstruction): Match state spans two tables — check the swipes table for Bob's swipe, then check the matches table for existing match. Two queries, two tables.

Why Directed still works: Match checks happen once per swipe. Feed queries happen on every app open — 10-100× more frequent. Optimizing for the common case (per-user queries) is usually the right trade-off.

The feed must exclude users already swiped on. How hard is this exclusion?

Directed Model (natural fit): "Who have I swiped on?" maps directly: SELECT swipee_id FROM swipes WHERE swiper_id = :me. One column, one index, one direction.

Pair Model (awkward): The user might be user_a or user_b depending on ID ordering. You must check both positions with an OR condition that complicates query planning and may require two index scans.

Premium feature: show everyone who liked me, even if I haven't swiped back.

Directed Model (natural fit): Incoming likes are first-class: SELECT swiper_id FROM swipes WHERE swipee_id = :me AND liked = TRUE. Index on (swipee_id, liked) makes this fast.

Pair Model (awkward): Same OR-condition problem. You must decode "other side liked me" from symmetric decision fields. Often requires building a separate incoming_likes projection — effectively adding a directional view.

At scale, you partition data across nodes. The shard key determines which queries stay local.

Directed Model offers two strategies:

• Shard by swiper_id: Feed exclusion is local (all my swipes on one shard), match detection is cross-shard
• Shard by pair key: Match detection is local, per-user queries become scatter-gather

Pair Model naturally shards by pair key: match state is local, but per-user views span many shards and require projection tables.

You can only optimize for one access pattern with a shard key. Choose based on which query dominates.

Indexes make or break performance at scale. Each model needs different indexes optimized for its primary access patterns.

Directed Model Indexes:

-- Primary: write path (swipe recording)
CREATE UNIQUE INDEX idx_swipes_pk ON swipes(swiper_id, swipee_id);

-- Feed exclusion: "who have I already swiped on?"
-- Covered index: query answers entirely from index, no table access
CREATE INDEX idx_swipes_swiper_covered ON swipes(swiper_id) INCLUDE (swipee_id);

-- Match detection: "did this person like me?"
CREATE INDEX idx_swipes_swipee_liked ON swipes(swipee_id, liked) WHERE liked = TRUE;

-- "Who liked me" (premium): incoming likes
-- Partial index: only indexes TRUE likes, ~50% smaller
CREATE INDEX idx_swipes_incoming_likes ON swipes(swipee_id, created_at DESC)
    WHERE liked = TRUE;

-- Matches: both users need to find their matches
CREATE UNIQUE INDEX idx_matches_pk ON matches(user_a, user_b);
CREATE INDEX idx_matches_user_b ON matches(user_b, created_at DESC);

Pair Model Indexes:

-- Primary: pair lookup and update
CREATE UNIQUE INDEX idx_pairs_pk ON user_pairs(user_a, user_b);

-- Matches: find all matched pairs involving a user
-- Requires scanning BOTH columns (OR condition)
CREATE INDEX idx_pairs_a_matched ON user_pairs(user_a) WHERE matched_at IS NOT NULL;
CREATE INDEX idx_pairs_b_matched ON user_pairs(user_b) WHERE matched_at IS NOT NULL;

-- Feed exclusion: find all pairs involving a user (any swipe state)
-- Two partial indexes needed, one for each position
CREATE INDEX idx_pairs_a_any ON user_pairs(user_a);
CREATE INDEX idx_pairs_b_any ON user_pairs(user_b);

Notice the Pair Model needs twice as many indexes for per-user operations because the user could be in either position (user_a or user_b). At 2B swipes/day, each additional index costs ~40-80 GB of storage.

Every user-facing action maps to specific backend operations. This mapping makes service boundaries concrete:

Inter-service communication: All service-to-service calls use synchronous gRPC for latency-critical paths (swipe → match check) and Kafka events for non-critical propagation (block → update all caches).

At small scale (< 1M DAU), a monolith is the right choice. The service split we describe is the destination architecture — where you'd evolve as scale demands.

Stage 1 (< 1M DAU): Single service, single database. All operations in one process. Database handles 1-5K writes/sec easily.

Stage 2 (1-5M DAU): Split the Candidate/Feed service out first — it's the easiest because it's read-only. Add Redis cache layer. Database still handles writes.

Stage 3 (5-20M DAU): Split Swipe Service with its own database. Shard by swiper_id. Add Kafka for async match detection.

Stage 4 (20M+ DAU): Full service split. Match Service gets its own database. Multi-region deployment. The architecture diagram above represents this stage.

Key principle: Don't pre-optimize. Each split introduces operational cost (deployment, monitoring, debugging). Split only when a specific bottleneck demands it.

The segment_pools table stores candidate_id and a lightweight score. Only after selecting the top N do you fetch full profiles:

def fetch_profiles(user_ids):
    # Multi-get from cache (single network call)
    profiles = cache.mget([f"profile:{uid}" for uid in user_ids])

    # Fetch cache misses from database
    missing = [uid for uid, p in zip(user_ids, profiles) if p is None]
    if missing:
        db_profiles = db.query(
            "SELECT id, name, bio, age FROM users WHERE id IN (?)", missing
        )
        photos = db.query(
            "SELECT user_id, url FROM photos WHERE user_id IN (?) ORDER BY position",
            missing
        )
        # Cache for next request (1-hour TTL, profiles change infrequently)
        cache.mset({f"profile:{p.id}": p for p in db_profiles}, ttl=3600)
    return profiles

Cache hit rate optimization: Preload profiles for top-scoring candidates during pool generation. When users open the app, their likely-to-see profiles are already warm in cache.

Precomputed pools rely on static location. When Alice flies from NYC to LA, her segment pool becomes useless.

Hybrid fetch detects travel and switches strategy:

def get_feed(user_id):
    current_location = get_current_location(user_id)  # GPS / IP
    if current_location.city == user.home_city:
        return get_feed_from_segment(user_id)  # Fast: precomputed pool
    else:
        return get_feed_from_geospatial(user_id, current_location)  # Live query

Geospatial tech options: Redis GEORADIUS (simple distance), PostGIS (compound filters), Elasticsearch (large-scale geo + text search). Start with Redis, migrate to PostGIS when compound filters are needed.

Location update strategy: Separate geospatial index (changes hourly, for real-time discovery) from home_city (changes after 30+ days sustained presence, for segment pool assignment). This prevents thrashing — a weekend trip to Vegas shouldn't rebuild your entire candidate pool.

After Bloom Filter exclusion, we have ~800 valid candidate IDs from the segment pool. Before returning 20 profiles, we rank them. The ranking pipeline has three stages:

Stage 1: Score Computation. Each candidate gets a composite score combining multiple signals:

def compute_score(candidate, user):
    recency = decay(candidate.last_active, half_life_hours=48)
    distance = 1.0 / (1.0 + km_distance(user, candidate))
    popularity = log(1 + candidate.likes_received_24h, 10)
    elo_match = 1.0 / (1.0 + abs(user.elo - candidate.elo))
    return (0.3 * recency + 0.25 * distance + 0.2 * popularity + 0.25 * elo_match)

Stage 2: Diversity Injection. Showing only top-scored candidates creates filter bubbles. Inject 10-20% random candidates to increase diversity. Use stratified sampling: pick 16 top-scored + 4 random from the remaining pool.

Stage 3: Position Bias Correction. Users swipe more generously on the first few profiles (position bias). Place medium-confidence candidates early and high-confidence at positions 5-8 where users are more selective.

A Bloom Filter is a probabilistic data structure that can tell you "definitely not in the set" or "probably in the set." For feed exclusion, false positives (incorrectly excluding a valid candidate) are harmless — the user just sees one fewer profile. False negatives (showing an already-swiped user) would be bad UX, but Bloom Filters never produce false negatives.

Sizing formula: For n items with false positive rate p:

• Bits needed: m = -n × ln(p) / (ln(2))²
• Hash functions: k = (m/n) × ln(2)

For a power user with 100,000 swipes and 0.01% false positive rate:

• m = -100,000 × ln(0.0001) / (ln(2))² = 1,917,011 bits ≈ 234 KB
• k = 13 hash functions

import mmh3
from bitarray import bitarray

class BloomFilter:
    def __init__(self, expected_items=100_000, fp_rate=0.0001):
        self.size = int(-expected_items * 2.302585 / (0.693147 ** 2) * abs(fp_rate))
        self.num_hashes = int(self.size / expected_items * 0.693147)
        self.bits = bitarray(self.size)
        self.bits.setall(0)

    def add(self, item):
        for seed in range(self.num_hashes):
            idx = mmh3.hash(str(item), seed) % self.size
            self.bits[idx] = 1

    def contains(self, item):
        return all(
            self.bits[mmh3.hash(str(item), seed) % self.size]
            for seed in range(self.num_hashes)
        )

Redis integration: Store the Bloom Filter as a Redis string (raw bytes). Use BF.ADD and BF.EXISTS commands from the RedisBloom module for server-side operations. This avoids transferring the entire filter to the application layer.

Pipelined alternative: For users with fewer than 1,000 swipes, a simple Redis SET + SISMEMBER is cheaper than maintaining a Bloom Filter. Use a threshold: Bloom Filter for users with >5,000 swipes, Redis SET for smaller users.

The offline batch job runs daily (typically 2-4 AM local time) and rebuilds segment pools:

def rebuild_segment_pools():
    segments = {}

    # Phase 1: Assign each user to their target segments
    for user in db.stream_all_active_users():
        # A user seeking "women aged 25-30 in NYC" maps to segment "nyc:female:25-30"
        target_segment = f"{user.city}:{user.preferred_gender}:{age_bucket(user.preferred_age_min, user.preferred_age_max)}"
        candidate_segment = f"{user.city}:{user.gender}:{age_bucket(user.age, user.age)}"

        if candidate_segment not in segments:
            segments[candidate_segment] = []
        segments[candidate_segment].append({
            "candidate_id": user.id,
            "score": compute_base_score(user),  # Pre-computed, not personalized
        })

    # Phase 2: Truncate large segments, keep top-scored candidates
    for seg_id, candidates in segments.items():
        candidates.sort(key=lambda c: c["score"], reverse=True)
        segments[seg_id] = candidates[:5000]  # Cap at 5,000 per segment

    # Phase 3: Atomic swap (write to new table, then rename)
    db.execute("CREATE TABLE segment_pools_new AS SELECT * FROM segment_pools WHERE 1=0")
    for seg_id, candidates in segments.items():
        db.batch_insert("segment_pools_new", [
            {"segment_id": seg_id, "candidate_id": c["candidate_id"], "score": c["score"]}
            for c in candidates
        ])
    db.execute("ALTER TABLE segment_pools RENAME TO segment_pools_old")
    db.execute("ALTER TABLE segment_pools_new RENAME TO segment_pools")
    db.execute("DROP TABLE segment_pools_old")

Age bucket strategy: 5-year buckets (18-22, 23-27, 28-32, 33-37, 38-42, 43-50, 51+). Users seeking "25-35" map to segments "25-27" + "28-32" + "33-37". Wider preferences span more segments but the union is still small (3-4 pool lookups vs a full table scan).

Shard key: hash(swiper_id) % num_shards

Put everything Alice does on one server. All of Alice's outgoing swipes — Alice→Bob, Alice→Carol, Alice→Dave — live on Alice's shard.

The win: Alice's feed generation is local. One query to Alice's shard returns everyone she's already seen. Feed exclusion becomes a single-shard operation.

The trade-off: Match detection becomes cross-shard. When Alice likes Bob, we write to Alice's shard, then send a network request to Bob's shard to check if Bob liked Alice. Every mutual swipe requires one cross-shard read (+5-10 ms).

Shard key: hash(min(user_a, user_b), max(user_a, user_b)) % num_shards

Put everything about Alice and Bob on the same server. Both Alice→Bob and Bob→Alice live together.

The win: Match detection is instant and local. Checking for Bob→Alice requires no network hop.

The fail: Alice's "already seen" list is scattered across every shard in the cluster. To generate Alice's feed, we must ask every single shard for her swipe history. This is scatter-gather, and at 256 shards, it kills performance.

The async match detection pipeline uses a Kafka consumer group with partition-aware processing:

# Kafka topic: 'swipe-events', partitioned by swipee_id
# This ensures all swipes FOR the same person route to the same consumer
# (avoiding duplicate match detection)

class MatchDetectionWorker:
    def __init__(self, consumer_group="match-detection"):
        self.consumer = KafkaConsumer(
            "swipe-events",
            group_id=consumer_group,
            value_deserializer=json.loads
        )
        self.batch = []
        self.batch_size = 100
        self.flush_interval_ms = 500

    def process(self):
        for message in self.consumer:
            event = message.value
            if event["liked"]:
                self.batch.append(event)

            if len(self.batch) >= self.batch_size or self.time_since_last_flush() > self.flush_interval_ms:
                self.flush_batch()

    def flush_batch(self):
        if not self.batch:
            return

        # Group by swipee to batch queries to the same shard
        by_swipee = defaultdict(list)
        for event in self.batch:
            by_swipee[event["swipee_id"]].append(event["swiper_id"])

        for swipee_id, swiper_ids in by_swipee.items():
            # Single batched query to swipee's shard (via read replica)
            reverse_likes = db.read_replica.query(
                "SELECT swipee_id FROM swipes "
                "WHERE swiper_id = %s AND swipee_id IN %s AND liked = TRUE",
                swipee_id, tuple(swiper_ids)
            )
            # reverse_likes contains IDs that swipee has liked back
            for match_partner in reverse_likes:
                create_match_if_not_exists(swipee_id, match_partner)
                send_push_notification(swipee_id, match_partner)

        self.batch.clear()

Partition strategy: Partition by swipee_id (not swiper_id). This ensures all "did X like me back?" checks for the same person route to the same consumer. Without this, two consumers might both detect (and both create) the same match.

Backpressure handling: If a consumer falls behind (e.g., celebrity user with 50K incoming swipes):

1. Consumer lag metrics trigger alerts at 10K messages
2. At 50K lag, auto-scale consumer instances for that partition
3. At 100K lag, shed low-priority checks (pass swipes) and focus on likes only

At 2B swipes/day, storage grows by ~80 GB daily (40 bytes per swipe). After 90 days, you're sitting on 7.2 TB. Most of this data is "cold" — users rarely look up swipes older than a few weeks.

Tiered storage strategy:

Compaction for pass swipes: Left swipes (passes) are only needed for feed exclusion ("don't show again"). After 30 days of Bloom Filter membership, the exact swipe record is redundant. Batch job compacts pass swipes older than 30 days:

-- Compact pass swipes: transfer to Bloom Filter, then delete records
WITH old_passes AS (
    SELECT swiper_id, swipee_id
    FROM swipes
    WHERE liked = FALSE
      AND created_at < NOW() - INTERVAL '30 days'
    LIMIT 100000
)
DELETE FROM swipes
WHERE (swiper_id, swipee_id) IN (SELECT swiper_id, swipee_id FROM old_passes);
-- Bloom Filter already contains these entries from the write path

This compaction reduces active storage by ~60% (most swipes are passes).

At 100K writes/sec peak, naive connection management becomes the bottleneck before the database does.

Connection pool sizing: With 16 shards and 8 Swipe Service instances:

• Max connections per shard: 8 instances × 20 connections = 160
• PostgreSQL max_connections per shard: 200 (leaving 40 for admin/monitoring)
• Total cluster connections: 16 × 200 = 3,200

Write batching with PgBouncer:

; pgbouncer.ini
[pgbouncer]
pool_mode = transaction
max_client_conn = 2000
default_pool_size = 50
reserve_pool_size = 10
reserve_pool_timeout = 3
server_lifetime = 3600

Transaction pooling mode releases the server connection after each transaction completes, allowing 2,000 application connections to share 50 actual PostgreSQL connections.

Prepared statements: The swipe INSERT is the same query 100K times/sec with different parameters. Prepared statements eliminate parsing overhead:

PREPARE insert_swipe (bigint, bigint, boolean) AS
    INSERT INTO swipes (swiper_id, swipee_id, liked) VALUES ($1, $2, $3);
EXECUTE insert_swipe(123, 456, true);

The race condition only exists because of how PostgreSQL's default isolation level (READ COMMITTED) handles concurrent transactions. Let's trace through the exact mechanics:

READ COMMITTED (PostgreSQL default):

• Each statement sees only rows committed before that statement began
• If Alice's INSERT is uncommitted when Bob's SELECT runs, Bob cannot see Alice's row
• This is why: INSERT(Alice→Bob) → SELECT(Bob→Alice) → invisible → MISS → no match

REPEATABLE READ:

• Each statement sees only rows committed before the transaction began
• Makes the race condition worse — even if Alice's INSERT commits before Bob's SELECT, Bob still sees the snapshot from transaction start
• Never use for this purpose

SERIALIZABLE:

• PostgreSQL detects read-write conflicts and aborts one transaction
• Would catch the simultaneous swipe race, but at heavy cost: retry logic for every aborted transaction, reduced throughput
• Too expensive for 23K writes/sec

The real fix is architectural, not isolation-level:

The recommended approach for most systems: Background reconciliation + inline optimistic check. The optimistic inline check catches 99.9% of matches instantly. The background job catches the 0.1% of race conditions within seconds.

def record_swipe_with_optimistic_match(swiper_id, swipee_id, liked):
    # Transaction 1: Write the swipe
    with db.transaction():
        db.execute("INSERT INTO swipes VALUES (%s, %s, %s)", swiper_id, swipee_id, liked)

    # Optimistic check (outside transaction, sees committed state)
    if liked:
        reverse = db.query_one(
            "SELECT 1 FROM swipes WHERE swiper_id=%s AND swipee_id=%s AND liked=TRUE",
            swipee_id, swiper_id
        )
        if reverse:
            try:
                db.execute(
                    "INSERT INTO matches (user_a, user_b) VALUES (LEAST(%s,%s), GREATEST(%s,%s))",
                    swiper_id, swipee_id, swiper_id, swipee_id
                )
                return {"matched": True}
            except UniqueViolation:
                return {"matched": True}  # Already created by the other side — still a match!

    return {"matched": False}

The UniqueViolation catch is key: if both sides detect the match simultaneously, one INSERT succeeds and the other gets a duplicate key error. We catch it and still return "matched" — the database's uniqueness constraint guarantees exactly one match row.

Many dating apps use an ELO-style rating system (borrowed from chess) to estimate "desirability" and improve feed quality:

class ELOSystem:
    K_FACTOR = 32  # How much each swipe moves the rating
    BASE_RATING = 1000

    def update_ratings(self, swiper_rating, swipee_rating, swipe_is_like):
        # Expected probability that swiper likes swipee
        expected = 1.0 / (1.0 + 10 ** ((swipee_rating - swiper_rating) / 400))

        # Actual outcome: 1 for like, 0 for pass
        actual = 1.0 if swipe_is_like else 0.0

        # Update swipee's rating based on who swiped on them
        swipee_new = swipee_rating + self.K_FACTOR * (actual - expected)

        # If a "high-rated" user likes a "low-rated" user, the low-rated user's
        # score increases more (they're "better than expected")
        return swipee_new

Cold start problem: New users have no ELO history. Solution: assign initial ELO based on profile completeness (photos, bio length, verification status) and boost for first 48 hours.

Decay: Inactive users' ELO decays toward the mean over 30 days. This prevents ghost profiles from clogging high-ELO tiers.

For premium users, we maintain a pre-materialized list of incoming likes in Redis:

# Write path: when someone likes a premium user, update their cache
def on_swipe_event(swiper_id, swipee_id, liked):
    if liked and is_premium(swipee_id):
        redis.zadd(
            f"incoming_likes:{swipee_id}",
            {swiper_id: time.time()}  # Score = timestamp for ordering
        )
        # Trim to most recent 500 likes
        redis.zremrangebyrank(f"incoming_likes:{swipee_id}", 0, -501)

# Read path: premium user views "Who Liked Me"
def get_incoming_likes(user_id, limit=20, cursor=None):
    max_score = cursor or "+inf"
    liker_ids = redis.zrevrangebyscore(
        f"incoming_likes:{user_id}",
        max_score, "-inf",
        start=0, num=limit
    )
    # Filter out already-swiped (user already decided on these)
    unswiped = [lid for lid in liker_ids
                if not bloom_filter.contains(f"swiped:{user_id}", lid)]
    profiles = fetch_profiles(unswiped)
    return profiles

Why a sorted set? The ZADD score (timestamp) enables cursor-based pagination and automatic deduplication. ZREVRANGEBYSCORE returns likes in reverse chronological order.

Blurred preview for free users: Free users see a count and blurred thumbnails of incoming likes. The blurred preview uses the same Redis sorted set but only returns the count and photo URLs (heavily degraded quality):

def get_blurred_likes_preview(user_id):
    count = redis.zcard(f"incoming_likes:{user_id}")
    recent_ids = redis.zrevrange(f"incoming_likes:{user_id}", 0, 2)
    blurred_photos = [get_blurred_photo(uid) for uid in recent_ids]
    return {"count": count, "preview": blurred_photos}

When Alice blocks Bob, the block must propagate through multiple systems:

async def block_user(blocker_id, blocked_id, reason):
    # Step 1: Record the block
    db.execute(
        "INSERT INTO blocks (blocker_id, blocked_id, reason) VALUES (%s, %s, %s)",
        blocker_id, blocked_id, reason
    )

    # Step 2: Invalidate cached data
    bloom_filter.add(f"blocked:{blocker_id}", blocked_id)
    bloom_filter.add(f"blocked:{blocked_id}", blocker_id)  # Bidirectional

    # Step 3: Soft-delete existing match (if any)
    db.execute(
        "UPDATE matches SET deleted_at = NOW() "
        "WHERE user_a = LEAST(%s,%s) AND user_b = GREATEST(%s,%s) AND deleted_at IS NULL",
        blocker_id, blocked_id, blocker_id, blocked_id
    )

    # Step 4: Publish block event (async propagation to all services)
    kafka.publish("block-events", {
        "blocker_id": blocker_id,
        "blocked_id": blocked_id,
        "timestamp": datetime.utcnow().isoformat(),
    })

    # Step 5: Clear from any active feed sessions (real-time)
    await websocket.send_to(blocker_id, {"type": "remove_card", "user_id": blocked_id})

Why bidirectional Bloom Filter entries? When Alice blocks Bob, both blocked:Alice includes Bob AND blocked:Bob includes Alice. This ensures feed generation for both users excludes the other, without requiring two table lookups per candidate.

Feed integration: The feed generation pipeline checks blocks alongside the swipe exclusion:

valid = [c for c in candidates
         if not bloom_filter.contains(f"swiped:{user_id}", c.id)
         and not bloom_filter.contains(f"matched:{user_id}", c.id)
         and not bloom_filter.contains(f"blocked:{user_id}", c.id)]  # Block check

Audit trail: All blocks are logged to an immutable audit table for safety reviews and dispute resolution. Reports trigger automated review workflows if a user accumulates >3 blocks within 24 hours.

Users are assigned a home region at signup based on their IP geolocation. This determines where their swipe and match data lives.

Region assignment logic:

def assign_home_region(user_ip, signup_location):
    geo = geoip_lookup(user_ip)
    # Map to nearest data center region
    region_map = {
        "North America": "us-east",
        "South America": "us-east",  # closest DC
        "Europe": "eu-west",
        "Africa": "eu-west",
        "Asia": "ap-south",
        "Oceania": "ap-south",
    }
    return region_map.get(geo.continent, "us-east")

def should_migrate_home_region(user_id):
    # Only migrate after 30+ consecutive days in new region
    locations = db.query(
        "SELECT region, date FROM user_location_history "
        "WHERE user_id = %s ORDER BY date DESC LIMIT 30",
        user_id
    )
    if len(locations) < 30:
        return None
    new_region = locations[0]["region"]
    if all(loc["region"] == new_region for loc in locations):
        return new_region  # User has been in new region for 30+ days
    return None

Migration process (when a user permanently moves):

1. Begin dual-write: new swipes written to BOTH old and new region
2. Background job copies historical data (swipes, matches) to new region
3. Verify data integrity with checksums
4. Atomic cutover: update user's home_region field
5. Stop dual-write, old data expires per retention policy

Why 30 days? Shorter thresholds cause thrashing for frequent travelers. A two-week vacation shouldn't trigger a full data migration (7 TB transfer per user with extensive history).

When Alice (US-EAST) swipes on Bob (EU-WEST), the request must be routed correctly:

Alice's phone → US-EAST API Gateway → US-EAST Swipe Service
  ↓ Write Alice's swipe to US-EAST (Alice's home shard)
  ↓ Publish event to Global Kafka: {swiper: Alice(US-EAST), swipee: Bob(EU-WEST)}
  ↓
Global Kafka → EU-WEST Match Detection Worker
  ↓ Read Bob's swipes from EU-WEST (Bob's home shard, read replica)
  ↓ If Bob liked Alice → Create match in BOTH regions
  ↓ Push notification to both Alice and Bob

DNS-based routing: Each user's home region is encoded in the API token. The API Gateway routes swipe writes to the swiper's home region, regardless of their current physical location. This means Alice on vacation in Paris still writes to US-EAST.

Global Kafka vs Regional Kafka:

Start with regional Kafka + MirrorMaker bridge between regions. Each region processes local events immediately, cross-region events arrive within seconds via replication.

Multi-region systems must handle partial failures gracefully:

Circuit breaker pattern: If cross-region match checks fail for 30+ seconds, stop attempting synchronous checks and rely entirely on async detection. Resume synchronous checks after the circuit heals.

class CrossRegionCircuitBreaker:
    def __init__(self, failure_threshold=5, recovery_timeout_s=30):
        self.failures = 0
        self.threshold = failure_threshold
        self.state = "CLOSED"  # CLOSED → OPEN → HALF-OPEN
        self.opened_at = None
        self.recovery_timeout = recovery_timeout_s

    def call(self, func, *args):
        if self.state == "OPEN":
            if time.time() - self.opened_at > self.recovery_timeout:
                self.state = "HALF-OPEN"
            else:
                raise CircuitOpenError("Cross-region checks disabled")

        try:
            result = func(*args)
            if self.state == "HALF-OPEN":
                self.state = "CLOSED"
                self.failures = 0
            return result
        except TimeoutError:
            self.failures += 1
            if self.failures >= self.threshold:
                self.state = "OPEN"
                self.opened_at = time.time()
            raise