Geo and seen-filtering — geohash, S2/H3, Bloom vs exact sets

Spatial indexing (the decision tree):

• Grid/geohash: encode lat/lng into a string prefix — nearby points share prefixes. Query = the cell + 8 neighbors (the classic "search 3×3 grid" pattern); prefix length controls precision (~5 chars ≈ 4.9 km, 6 ≈ 1.2 km, 7 ≈ 150 m). Cheap, index-friendly (B-tree prefix scan), approximate cell boundaries.
• S2 / H3: hierarchical cell systems with better geometry (S2: spherical quadtree, arbitrary rectangles; H3: hexagonal, uniform neighbor distance) — production-grade for global apps.
• Quadtrees: dynamic subdivision; good in-memory; less natural in SQL.
• PostGIS/earthdistance: real geometry (polygons, distance, containment) — the correct choice when you need actual shapes.
• Redis GEO: sorted-set encoding (52-bit geohash in a zset score) with GEOADD/GEOSEARCH — sub-ms nearby queries for hot paths (the "Redis GEO hot path" from your list: cache the hot radius search, back it with the database).

Point-in-polygon / geofencing: ray casting (count crossings of a ray from the point — odd = inside) is the classic algorithm; winding number is the robust variant; both are O(vertices) per test — fine for modest polygons, which is why geofences are usually few and cached. Real systems precompute bounding boxes (reject fast) then run ray casting on candidates.

Seen filtering (your Bloom-vs-exact question, in its natural habitat): "have I already shown this user this item?" — the canonical feed/dedup filter.

• Exact set (Redis SET / Postgres table): correct, memory ∝ items. Fine to ~millions per user-batch, expensive at massive scale.
• Bloom filter: O(10 bits/item), ~1% false positives — and the failure mode matters: a false positive means "already seen" for something unseen → the item is silently skipped (acceptable for feed dedup, never for authorization). Also: Bloom filters can't be deleted from (no per-item removal) and are per-keyed-set (per-user filters for 100M users = 100M filters — the scale trap; the alternatives are counting Bloom, cuckoo filters (deletable), or a shared filter with per-item TTL semantics).
• Your projects: exact filtering, correctly — traverse's hiddenUserIds (blocks), dedup by unique constraints, "already solved" via Solve uniqueness, seen-sets as indexed queries. The right sentence: "I use exact membership everywhere because my sets are small and my false-positive tolerance is zero — Bloom earns its keep when the set exceeds memory and a false positive costs a wasted lookup (feed dedup), never a wrong decision."

Matching/recommendation algorithms (the topic list's tail): rule-based scoring (attribute overlap), collaborative filtering (co-occurrence: users who did X also did Y — computable in SQL at small scale via self-joins), and embedding similarity (your pgvector pattern: embed items/users, nearest neighbors). The systems framing: recommendation quality is a modeling problem; the systems problem is candidate generation (index-friendly retrieval) + scoring + caching, and the honest note for traverse: friend suggestions and problem recommendations would start as SQL co-occurrence queries — no ML infra needed until quality demands it.