Design a Stock Trading Collaboration Chat

Problem statement

Design a collaboration chat platform for professional trading desks, analysts, and sales teams: group channels organized by market segment (US equities, derivatives, FX, credit), real-time quote and chart embedding, trade proposals that can escalate into actual order entry against a broker or exchange gateway, and strict role-based permissions across junior, senior, and lead roles. Every message, edit, deletion attempt, quote embed, and order action must be archived for financial regulators and made searchable for internal surveillance.

This is not a generic chat design. Three distinct consistency and risk domains are stacked on a single transport, and the design fails if you collapse them:

1. Message correctness — channel-scoped causal ordering, no gaps, no duplicates, durable before fan-out.
2. Market-data freshness — last-value-wins per symbol, aggressive coalescing, explicitly stale-tolerant.
3. Order safety — idempotent, authorized, dual-approved, FIX-level exactly-once semantics with no tolerance for duplicate submission.

A chat message can be delivered at-least-once and deduplicated client-side. A trade order cannot. A quote tick can be dropped under pressure; a compliance journal record cannot. The architecture must state which domain each byte belongs to and give each domain its own delivery contract.

Why the problem is distinctive

A Slack-style backend retries a notification. A trading chat backend that retries an order submission can double-fill a position. A Discord-style presence system tolerates stale online dots; a surveillance system cannot tolerate an unattributed message. The problem requires group channels per market segment, real-time quote/chart embedding, possible order entry, role-based permissions, financial compliance, low latency, org-scale scalability, and legal archiving. fileciteturn0file2 fileciteturn0file3

Public operating baseline versus design assumptions

Public figures establish that every sub-problem is operationally real. Discord reports 200M+ MAU and has publicly described single-guild concurrency in the millions handled by Elixir gateways plus Rust presence services. Slack reports 30M+ DAU and has described Vitess-sharded MySQL at the core of its message store. WhatsApp has publicly reported 100B messages per day on Erlang/OTP infrastructure. Bloomberg reports distributing tens of millions of market-data updates per second through B-PIPE. These are company-reported context figures, not our design targets.

For capacity planning, this answer explicitly assumes a mature deployment: 200,000 daily active traders, 40,000 concurrent WebSocket connections at peak, 60 million messages per day, and a 5x market-open event peak. Every uncited number below is a stated assumption, budget, or threshold.

The four architectural planes

1. Messaging plane: channels, ordered durable messages, edits, reactions, mentions, delivery receipts.
2. Market-data plane: feed ingestion, normalization, per-symbol last-value cache, subscription registry, throttled fan-out.
3. Order plane: proposals, RBAC checks, dual approval, OMS gateway, FIX sessions, execution reports.
4. Compliance plane: append-only journal, WORM/electronic archive, surveillance rules, eDiscovery export, retention policy.

A strong answer keeps these planes separate. The compliance plane must observe the messaging plane without slowing interactive delivery; the order plane must never inherit the at-least-once semantics of chat fan-out; and market-data overload must degrade quote cadence before it degrades message delivery.