Design Slack

March 13, 2022 7:00 PM PDT

---

Topic: Design Slack
Level: L5 (Senior)
Duration: 45 minutes

Overview

The meeting focused on a mock system design interview for a chat application similar to Slack. The discussion covered both functional and non-functional requirements, system design, database design, and various technical considerations related to message handling, user interactions, and scalability.

Requirements

Functional Requirements

• Design a chat application with the following features:
  • 1-1 messaging and group chat
  • User management
  • Channel management
  • Workspace organization
  • Message archiving and offline messaging
  • Keyword search functionality
  • Support for public and private channels
  • Multi-device access (mobile, app, web)

Non-Functional Requirements

• High availability
• Low latency
• Scalability
• Daily Active Users (DAU): 1,000,000
• Workspaces: 100,000
• Channels: 1,000,000
• Total users: 10,000,000
• Target users per workspace: 10,000
• Average messages per user per day: 10
• Average message length: 100 bytes
• Storage requirement for 3 years: 1 TB (can scale to 10 TB if average messages increase)

System Design

External APIs

• Login: Authenticate users using UID and credentials.
• Messaging:
  • send_to_user(from_uid, to_uid, wid, msg)
  • send_to_channel(from_uid, to_cid, wid, msg)
  • retrieve_u2u_messages(to_uid, wid, start_time, end_time)
  • retrieve_u2c_messages(to_uid, wid, start_time, end_time)
  • search(uid, cid, wid, keyword)
  • add_channel / remove_channel / modify_channel

High-Level System Design

• Utilize WebSocket for real-time message sending and receiving.
• Messages can be sent via HTTP requests and received through WebSocket connections.
• Implement a load balancer (LB) to manage traffic and distribute it to workers.
• Workers handle user-to-user and user-to-channel messages, ensuring efficient communication.

Database Design

• Metadata Database: Relational DB for users, channels, and channel-to-user mappings.
• Message Database: Non-SQL DB for storing messages in a log-based structure.
  • Two types of logs: channel log and user inbox.
  • Use an LSM tree or LevelDB for efficient message storage.

Message Handling

• User-to-user messages are pushed directly to the user's inbox.
• User-to-channel messages are first stored in the channel log and then fan-out to users' inboxes.
• Separate recent message DB from archived messages for performance optimization.

Technical Considerations

• Ordering: Ensure messages are delivered in the correct order using timestamps.
• Causality: Guarantee that read-write operations are directed to the same node.
• Load Balancer: Essential for managing a large number of clients and ensuring efficient distribution of requests.
• WebSocket Connections: Maintain connections through a middle tier to handle service discovery and backend communication.

Feedback

• The interviewer noted that the case was comprehensive but suggested simplifying the model.
• Emphasis on understanding the importance of covering all components and user scenarios in the design.
• The interviewee was encouraged to refine terminology and focus on real-world product experience.

Conclusion

The discussion highlighted the complexities involved in designing a scalable chat application, emphasizing the importance of both functional and non-functional requirements, as well as the need for efficient database and message handling strategies.