Design a Crypto Trader Chat

Problem statement

Design a chat platform where cryptocurrency traders discuss markets in real time. Each top asset gets a public channel, users post messages and react to live prices, tickers from multiple exchanges stream beside the conversation, verified analysts post with badges, moderators keep rooms safe, and — because the product sits next to an exchange — a message can deep-link into a prefilled order ticket.

This is not a generic chat clone. Three properties make it distinctive. First, the workload is volatility-coupled: a 10% BTC move or an ETF headline can multiply message volume, connection count, and ticker subscriptions within minutes, and the system must absorb that without losing messages or orders. Second, the read path is dominated by broadcast: one message in the BTC room must reach hundreds of thousands of concurrent readers, which inverts the fan-out economics of a private-messaging system. Third, money is adjacent: price data correctness, scam prevention, and order-safety are trust requirements, not features.

The four planes

1. Chat plane: durable per-channel message timeline, WebSocket delivery, presence, unread state, reactions.
2. Market data plane: ingestion from multiple exchange feeds, normalization, consensus price computation, and 1 Hz broadcast of tickers.
3. Trading plane: order deep-links from chat, KYC gating, idempotent order submission, risk confirmations.
4. Trust-and-safety plane: link scanning, scam and impersonation detection, moderation queues, enforcement ladder, audit.

A strong answer keeps the planes decoupled: a market-data ingestion stall must freeze tickers, not chat; a moderation classifier outage must degrade to inline-safe-mode, not block delivery; and a chat surge must never starve order acknowledgements.

Public operating baseline

Public evidence shows the category is real and large. Binance disclosed more than 200 million registered users in late 2023 and documents WebSocket market-data streams that update as fast as every 100 milliseconds. Telegram, a primary venue for crypto communities, reported roughly 950 million monthly active users in 2024 and scales channels to unlimited subscribers using pure broadcast. Discord, the de facto home of many trading communities, publicly describes message storage partitioned by channel and bucket in ScyllaDB and presence services built to hold millions of concurrent connections. These are cited context figures; every capacity target below is an explicitly stated design assumption.

For this interview we assume a mature product: 5 million MAU, 800 thousand DAU, 250 thousand concurrent WebSocket connections at peak, 32 million messages per day average, and a volatility multiplier of up to 10x on message rate in affected coin rooms. Unless a number is tied to a citation, it is a stated assumption.

What makes this hard

The five genuinely hard problems are: multi-exchange feed merging under clock skew and out-of-order delivery; broadcast fan-out to mega-channels during volatility spikes; WebSocket gateway state at hundreds of thousands of connections with zero-downtime drain; crypto-specific abuse at wire speed (phishing links, impersonation of exchange staff, pump-and-dump coordination); and safe trading integration where a chat action must never become an accidental or replayed order. The rest of the interview is a systematic walk through these.