Design Slack-like multi-tenant global messaging system

Design a team messaging platform similar to Slack that supports multiple organizations (multi-tenancy) and is deployed globally.

Functional requirements

• Users can belong to one or more workspaces (tenants/organizations).
• Each workspace has multiple channels (public and private) and direct messages (DMs) .
• Users can:
  • Send and receive real-time text messages in channels and DMs.
  • See message history in channels and DMs.
  • See basic presence (online/away) for other users in the same workspace.
• Messages must be delivered with low latency (e.g., p95 < 200 ms) for active users.

Non-functional & multi-tenant requirements

• The service must support millions of users across tens of thousands of workspaces .
• Multi-tenancy :
  • Strict data isolation between workspaces: users in one workspace must never see data from another workspace.
  • Different workspaces can have different configurations and limits (e.g., message retention, file size limits).
  • The system should defend against noisy neighbors (one tenant over-consuming shared resources).
• Global deployment :
  • Users are geographically distributed (e.g., Americas, Europe, Asia).
  • Users should connect to a nearby region for good latency.
  • Many large organizations have employees in multiple regions in the same workspace .

Design tasks

Describe a design that covers at least the following aspects:

1. API and high-level architecture
   • Key services (e.g., gateway/API layer, auth, workspace/channel management, messaging, presence, search, notification).
   • How clients (web/desktop/mobile) connect to the system for real-time messaging (e.g., WebSockets, long polling).
2. Data model and storage
   • Core entities: Workspace (Tenant) , User , Membership , Channel , Message .
   • What storage technologies you would use for:
     • Metadata (users, workspaces, channels, memberships).
     • Messages and their history.
   • How you would partition/shard data to scale to many tenants and users.
3. Multi-tenant architecture
   • How you will represent tenant boundaries in the data model and APIs (e.g., tenant_id everywhere).
   • Options for physically storing tenant data: fully shared DB with a tenant_id column, separate DB per tenant, or a hybrid; discuss pros/cons.
   • How you enforce security and isolation across all layers (auth, services, storage).
   • Handling noisy neighbors (rate limiting, quotas, priority or dedicated resources for large tenants).
4. Global deployment and replication
   • How you would deploy the system into multiple regions.
   • How users get routed to the closest region (e.g., DNS, anycast, global load balancers).
   • How data for a single global workspace is handled when users are in multiple regions:
     • Where is the source of truth for messages of a workspace?
     • How are messages replicated across regions (e.g., asynchronous replication, regional caches)?
     • What consistency guarantees do you provide (e.g., eventual consistency across regions vs strong consistency within a region)?
   • Strategies for regional failover and disaster recovery.
5. Scalability and performance
   • How you would scale:
     • WebSocket / real-time connections.
     • Message fan-out to many subscribers in a busy channel.
     • Message storage and retrieval.
   • Caching strategies and indexing for recent history vs deep history.
6. Other considerations (at a high level)
   • Search and message indexing across channels in a workspace.
   • File attachments (storage and access controls) if you have time.
   • Security (encryption in transit/at rest, per-tenant encryption keys, audit logging).

Explain the trade-offs you are making (e.g., consistency vs availability, shared vs isolated tenant storage) and justify your choices in terms of reliability, cost, and operational complexity.