Problem Statement: A Multi-Tenant Real-Time Collaboration Platform
Frames Slack Channels as a workspace-isolated, real-time messaging system with channels, threads, files, bots, and enterprise-grade security.
Problem statement
Design a workspace-centric real-time messaging platform modeled on Slack Channels. The system must support workspace creation and administration, public and private channels, direct messages, threaded conversations, file uploads, slash commands, bot integrations, searchable message history, and enterprise security controls. Every workspace is an isolated multi-tenant domain with its own users, channels, messages, files, and administrative policies.
This is not a simple chat application. A single enterprise workspace can contain 50,000+ members, thousands of channels, and billions of messages. Messages must appear in recipients' clients within 200 milliseconds of being sent, even when a channel has 10,000 concurrent readers. File uploads must support documents up to 1 GB. Slash commands must execute within 3 seconds. Search must return relevant results from billions of messages in under 500 milliseconds. And the entire platform must satisfy SOC 2, HIPAA, GDPR, and FedRAMP compliance requirements for enterprise adoption.
Why this problem is distinctive
A social media feed can tolerate seconds of propagation delay. A messaging platform cannot. The user expectation for chat is conversational immediacy: if Alice sends a message, Bob must see it before he finishes reading his own reply. This sub-200ms delivery requirement, combined with fan-out to potentially thousands of concurrent readers per channel, makes the real-time delivery path the hardest engineering problem in the system.
The multi-tenant dimension adds a second layer of complexity. Every workspace is a security boundary. Messages in Workspace A must never leak into Workspace B, even though both may share the same database cluster, the same search index, and the same WebSocket connection pool. Data partitioning, query isolation, and access control must be enforced at every layer.
The four architectural planes
- Real-time plane: WebSocket connection management, message fan-out, presence, typing indicators, and delivery acknowledgements.
- Persistence plane: Message storage, channel membership, user profiles, file metadata, and workspace configuration.
- Search and intelligence plane: Full-text search indexing, slash command execution, bot framework, and link unfurling.
- Governance plane: Workspace administration, role-based access control, audit logging, compliance retention, and enterprise key management.
A strong interview answer keeps these planes separate. The real-time plane must degrade without corrupting the persistence plane. The search plane must lag without blocking message delivery. The governance plane must enforce policy without adding latency to the hot path.
Key Highlights
- •Messages must reach all concurrent channel readers within 200ms p95, even in channels with 10,000+ members.
- •Every workspace is an isolated multi-tenant security boundary enforced at database, cache, search, and WebSocket layers.
- •The system has four planes: real-time delivery, persistence, search/intelligence, and governance.
- •Public Slack figures provide context; every uncited scale or SLO in this answer is an explicit design assumption.
- •Thread model uses parent_ts linking, not separate thread storage, keeping queries simple at the cost of scan width.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate real-time delivery from durable storage: the former must be fast, the latter must be correct."
- "Before selecting databases, let me define which operations are on the 200ms hot path and which can tolerate seconds of latency."