I Built a Serverless Stranger-Matching Tool with Zero Database — Here is the Architecture

Wen Durai — Fri, 26 Jun 2026 01:50:19 +0000

The elevator pitch

You open fata.uk, write a few lines about what is on your mind, and AI finds a stranger whose emotional frequency matches yours. Then it gives you each other’s email and exits. No app. No signup. No database. No chat history.

The architecture (or: how to build a social product with no server)

The entire backend is a single Cloudflare Worker. State lives in GitHub Issues. Here is the flow:

Browser (signal heuristic, ms-level)
  → HMAC-signed POST → Cloudflare Worker
    → BGE-M3 embedding API (1024-dim)
    → AES-256-GCM encrypt → GitHub Issues (encrypted pool)
    → Multi-channel scoring → MMR diversity rerank
    → Match found? → Internal LLM resonance → Resend email

Layer 1: Browser-side signal density

Before any API call, the browser computes four heuristics on the user’s text: length, lexical diversity, sentence count, and concrete detail markers. Score < 0.3? Gentle nudge to write more. Score < 0.15 on the server side? Rejected. This filters out noise before it hits the pool.

Layer 2: Proof-of-Work gate

Every submission requires solving a SHA-256 PoW challenge (difficulty 16 — ~1-2s on mobile). The solution is verified server-side, and a short-lived submit token (30 min TTL) is issued. Combined with per-IP and per-email rate limits, this makes automated abuse economically unattractive.

Layer 3: Embedding with fallback chain

The Worker calls SiliconFlow’s BGE-M3 embedding API (1024-dim). If that fails, it falls back to the browser-provided TF-IDF embedding. If both fail, server-side TF-IDF is computed. The original text is discarded after embedding — the vector cannot be reversed back to words.

Layer 4: GitHub Issues as an encrypted matching pool

This is the part I find most fun. Sensitive data (email, embedding, text snippet) is AES-256-GCM encrypted and stored in Cloudflare KV. Only metadata (language, embedding type, key version) goes into the GitHub Issue body. The pool is public but every entry is ciphertext.

Layer 5: Multi-channel matching + MMR rerank

The matching engine scores candidates across four channels:

Semantic similarity (cosine similarity on embeddings, weight 0.30)
Intent compatibility (LLM-parsed emotional need, weight 0.40)
Style compatibility (responsive vs. expressive, weight 0.15)
Signal bounce (signal density product, weight 0.15)

Top candidates are reranked with MMR (Maximum Marginal Relevance) to ensure diversity in the matched pool.

Layer 6: AI writes the introduction, then disappears

When a match is found, an internal LLM call generates a short resonance paragraph and three icebreaker questions. Both users receive each other’s email via Resend. After that, fata is out of the picture — all further communication happens in the user’s own email client.

The security story

Key separation: HMAC_KEY (API signing, frontend-visible) ≠ ENCRYPTION_KEY (data at rest, Worker secret only)
Rate limiting: Two-layer (in-memory + KV), fail-closed. If KV is unreachable, requests are rejected — not passed through.
PoW + email cap: 3 submissions per email per day + 500 global daily cap
2026-06-20 incident: A public /api/hmac-key endpoint was discovered and abused for LLM proxy spam (3.49 billion tokens in one day). Fixed within hours. All public LLM endpoints deleted. Postmortem in the repo.

Why email instead of in-app chat?

Every "anonymous chat" product eventually faces the same trust problem: users have to believe the platform when it says it does not read their messages. fata solves this by making it architecturally impossible to read messages — because the messages are not in fata. They are in your Gmail.

Stack

Static HTML page (single file)
  → Cloudflare Worker (fata.uk/api/*)
  → GitHub Issues (encrypted pool)
  → Cloudflare KV (sensitive data, 30-day TTL)
  → SiliconFlow BGE-M3 (embedding)
  → SiliconFlow DeepSeek V3 (resonance LLM)
  → Resend (email)

Try it

fata.uk — open in any browser.

Source: github.com/gsailing19/fata (MIT)

If you have built something with "impossible" architecture — zero servers, zero databases, or a constraint that shaped the product in unexpected ways — I would love to hear about it in the comments.

DEV Community: Wen Durai