Design an Anonymous Confession/Support Chat

Problem statement

Design an anonymous confession and emotional-support chat platform. Users arrive under pseudonyms, with no name, email, phone number, or persistent profile. The system either pairs them one-on-one with a trained volunteer listener or places them into a moderated peer group room. Every message must pass through a safety pipeline that detects self-harm and abuse categories, and acute crisis signals must escalate to trained responders within seconds.

This is not a generic chat app with a privacy toggle. Three properties make it distinctive, and each one shapes the architecture.

1. Anonymity is the product

Users disclose things they would never attach to a real identity. If the system logs personally identifiable information, correlates sessions to devices, or leaks IPs into analytics, it betrays the core promise and exposes vulnerable people. Privacy here is not a compliance checkbox; it is the reason the service exists. That forces hard decisions: what identity means without accounts, how to stop abuse without deanonymizing anyone, and how to delete data so that deletion is real.

2. Safety detection is latency-critical and harm-critical

A missed toxicity flag is an annoyance. A missed acute-crisis flag is a potential loss of life. The moderation plane therefore has two very different service levels: high-volume abuse classification, which can be asynchronous and statistical, and crisis detection, which must be high-recall, prioritized, and connected to human escalation with a seconds-scale SLO. One pipeline, two urgency classes.

3. Volunteers are a bounded capacity resource

Unlike WhatsApp, where every user can talk to every other user, one-on-one support requires a trained human on the other side. Volunteer supply is scarce, bursty, and correlated with demand (nights, weekends, and news events drive both). Matching is therefore a queueing problem with admission control, not just a socket fan-out problem.

The four architectural planes

1. Identity and session plane: ephemeral pseudonymous identities, device-bound keys, short-lived tokens, rate limiting, ban-evasion resistance without PII.
2. Conversation plane: WebSocket gateways, rooms, ordered delivery, presence, typing signals, reconnect reconciliation.
3. Trust-and-safety plane: inline synchronous filter, asynchronous ML classification, crisis routing, human review console, enforcement, appeals, evidence retention.
4. Operations plane: volunteer scheduling, matching queues, capacity dashboards, geo policy, legal disclaimers, aggregate metrics.

A strong interview answer keeps these planes separate. The conversation plane must degrade without weakening the safety plane, and the safety plane must keep functioning when analytics, recommendations, or volunteer dashboards fail.

Public operating baseline versus design assumptions

The category is operationally real. Crisis Text Line has publicly reported processing over 100 million messages through its volunteer-counselor network. 7 Cups publishes company-claimed figures in the hundreds of thousands of volunteer listeners across more than 180 countries. Meta's quarterly enforcement reporting describes millions of suicide-and-self-injury content actions per quarter with proactive detection. Twitch reported roughly 17.5 billion chat messages in 2020, and WhatsApp announced 100 billion messages per day, which anchors what real-time chat infrastructure looks like at scale. These are cited as context.

For capacity planning, this answer assumes a mature service with 500,000 DAU, 1.8 million MAU, 150,000 support sessions initiated per day, 60,000 peak concurrent connections, and a 5x surge multiplier. Unless tied to a published figure, every number in this answer is an explicitly stated design assumption.