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

A developer built fata.uk, a serverless stranger-matching tool that uses a single Cloudflare Worker, GitHub Issues for state, and Cloudflare KV for encrypted data. The system computes emotional frequency from text embeddings via BGE-M3, matches strangers using multi-channel scoring and MMR reranking, then delivers email addresses via Resend without storing chat history. The architecture makes it impossible to read messages since they exist only in users' email clients.

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 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 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. 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. 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. 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. The matching engine scores candidates across four channels: Top candidates are reranked with MMR Maximum Marginal Relevance to ensure diversity in the matched pool. 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. HMAC KEY API signing, frontend-visible ≠ ENCRYPTION KEY data at rest, Worker secret only /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.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. 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 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.