Katkat
Back

Design Slack-like multi-tenant global messaging system

OpenAISoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a global, multi-tenant messaging platform that handles high-concurrency real-time delivery, data isolation, and low-latency synchronization across distributed environments.

Problem Statement

Design a Slack-like messaging system that supports millions of daily active users across thousands of distinct organizations (tenants). The system must provide real-time messaging, persistent chat history, and notification delivery.

Requirements

  • Functional: Users can send messages in channels or direct messages; users see presence status (online/away/offline); messages must be persisted.
  • Non-functional: High availability; low latency (message delivery < 200ms); strong data isolation between tenants; support for global scale with regional presence.

Deliverables

  1. API Design: Define core endpoints for sending messages, fetching message history, and status updates.
  2. Data Model: Propose a database schema that handles multi-tenancy effectively (e.g., shared vs. isolated databases) while maintaining query performance.
  3. Architecture: Describe the message delivery flow, including the use of WebSockets, load balancers, and message queues.
  4. Scalability: Explain how you handle spikes in traffic for a single large organization without impacting others (the 'noisy neighbor' problem).

Example Context

  • 10,000 tenants, ranging from small teams to enterprises with 50,000+ users.
  • Global traffic patterns with peaks during local business hours.
  • Messages should be stored with a monotonically increasing ID or timestamp-based sequence.

Hints

Hint 1

Consider the trade-offs between shared database tables with a 'tenant_id' column versus dedicated physical database instances for each tenant.

Hint 2

Use a WebSocket-based gateway service to maintain persistent connections, but offload the actual message persistence to an asynchronous queue to ensure non-blocking message delivery.

Hint 3

Implement a sharding strategy based on 'workspace_id' or 'tenant_id' to ensure data locality and prevent a single organization's traffic from overwhelming global resources.

Follow-up questions

  • How would you handle the 'fan-out' problem if a user sends a message to a channel with 100,000 members?
  • How would you ensure data consistency for message history across multiple geographic regions?
  • If a specific tenant reports performance degradation, what monitoring metrics would you check to identify if it is a 'noisy neighbor' issue?