Group messaging in HLD - System Design Exercise

Design: Group Messaging System

Design covers backend architecture, data storage, real-time messaging, and APIs. Client UI design and multimedia messages are out of scope.

Functional Requirements

FR1: Users can create groups and add/remove members

FR2: Users can send messages to groups they belong to

FR3: Messages are delivered to all group members in real-time

FR4: Users can see message history in groups

FR5: Support text messages with timestamps and sender info

FR6: Support up to 100,000 concurrent users

FR7: Ensure message delivery latency under 200ms (p99)

FR8: Ensure 99.9% system availability

Non-Functional Requirements

NFR1: Handle up to 10,000 groups active simultaneously

NFR2: Store message history for at least 30 days

NFR3: Support mobile and web clients

NFR4: Secure user authentication and authorization

NFR5: Scalable to growing user base

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway for client requests

Authentication and Authorization service

Group Management service

Messaging service with real-time delivery

Message storage database

Cache for recent messages

Notification service for offline users

Design Patterns

Publish-Subscribe for message delivery

Event-driven architecture for message processing

CQRS for separating read and write workloads

Sharding for database scalability

Caching for fast message retrieval

Reference Architecture

Client (Web/Mobile)
   |
   v
API Gateway --- Auth Service
   |
   v
Group Management Service <--> User DB
   |
   v
Messaging Service <--> Message DB
   |
   v
Real-time Delivery (WebSocket Server)
   |
   v
Clients

Cache Layer (Redis) between Messaging Service and Clients
Notification Service for offline users

Components

API Gateway

Nginx or Envoy

Handles client requests, routes to backend services, enforces rate limits

Authentication Service

OAuth 2.0 / JWT

Verifies user identity and issues tokens for secure access

Group Management Service

REST API with stateless microservice

Manages group creation, membership, and permissions

Messaging Service

Event-driven microservice with message queue (e.g., Kafka)

Processes incoming messages, stores them, and publishes to subscribers

Message Database

NoSQL DB like Cassandra or DynamoDB

Stores messages with timestamps and sender info, supports fast writes and reads

Cache Layer

Redis

Caches recent messages for quick retrieval and reduces DB load

Real-time Delivery Server

WebSocket server cluster

Maintains persistent connections to clients for instant message delivery

Notification Service

Push notification system (Firebase, APNs)

Sends alerts to offline users about new messages

Request Flow

1. User authenticates via API Gateway and receives JWT token

2. User creates or joins a group via Group Management Service

3. User sends a message to a group through API Gateway to Messaging Service

4. Messaging Service stores message in Message DB and publishes event to message queue

5. Real-time Delivery Server subscribes to message queue and pushes message to connected group members

6. Cache Layer updates recent messages for fast access

7. Offline users receive notifications via Notification Service

8. Users fetch message history from Message DB or Cache when opening group chat

Database Schema

Entities: - User: user_id (PK), username, password_hash, created_at - Group: group_id (PK), group_name, created_at - GroupMember: group_id (FK), user_id (FK), role, joined_at - Message: message_id (PK), group_id (FK), sender_id (FK), content, timestamp Relationships: - User to GroupMember is 1:N (a user can be in many groups) - Group to GroupMember is 1:N (a group has many members) - Group to Message is 1:N (a group has many messages) - Message references sender User

Scaling Discussion

Bottlenecks

Real-time delivery server overwhelmed by large groups with many members

Message database write throughput limits with high message volume

Cache invalidation and consistency challenges

Authentication service latency under heavy load

Network bandwidth for pushing messages to many clients

Solutions

Partition real-time servers by group or user shards; use horizontal scaling

Use distributed NoSQL databases with write-optimized design and sharding

Implement cache expiration and update strategies; use eventual consistency

Deploy authentication service with autoscaling and token caching

Use efficient message encoding and batch notifications to reduce bandwidth

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Emphasize real-time message delivery and low latency

Discuss data consistency and message durability

Explain choice of technologies for scalability and availability

Highlight security with authentication and authorization

Address offline user handling and notification strategy

Practice

1. What is the primary purpose of a group messaging system?

easy

A. To allow multiple users to send and receive messages in a shared conversation

B. To store user passwords securely

C. To manage user profile pictures

D. To provide video streaming services

Solution

1. Step 1: Understand group messaging basics

   Group messaging connects multiple users so they can communicate together in one conversation.

2. Step 2: Identify the main function

   The main function is sending and receiving messages among group members, not unrelated features like password storage or video streaming.

3. Final Answer:

   To allow multiple users to send and receive messages in a shared conversation -> Option A

4. Quick Check:

   Group messaging = shared conversation [OK]

Hint: Focus on the core feature: multi-user message exchange [OK]

Common Mistakes:

• Confusing group messaging with unrelated features
• Thinking it only supports one-to-one chat
• Ignoring the shared conversation aspect

2. Which component is essential for managing who belongs to a group in a group messaging system?

easy

A. Group management

B. Notification service

C. Message storage

D. Media transcoding

Solution

1. Step 1: Identify components related to user membership

   Group management handles adding, removing, and listing members in a group.

2. Step 2: Exclude unrelated components

   Message storage saves messages, notification service alerts users, and media transcoding processes media, none manage group membership.

3. Final Answer:

   Group management -> Option A

4. Quick Check:

   Group membership = Group management [OK]

Hint: Group membership is handled by group management component [OK]

Common Mistakes:

• Confusing message storage with membership control
• Assuming notification service manages members
• Mixing media processing with group functions

3. Consider a group messaging system where each message is sent to all group members. If a group has 100 members and one message is sent, how many message deliveries occur?

medium

A. 1

B. 50

C. 101

D. 100

Solution

1. Step 1: Understand message delivery in group messaging

   Each message is delivered to every member of the group.

2. Step 2: Calculate total deliveries

   With 100 members, one message results in 100 deliveries (one per member).

3. Final Answer:

   100 -> Option D

4. Quick Check:

   Deliveries = group size = 100 [OK]

Hint: One message reaches all members, so deliveries = group size [OK]

Common Mistakes:

• Counting the sender as extra delivery
• Assuming half the group receives the message
• Confusing message count with delivery count

4. A group messaging system stores messages but users report delays in receiving messages. Which issue is most likely causing this delay?

medium

A. Message storage is too fast

B. Notification service is slow or failing

C. Group management is adding too many users

D. User profile pictures are too large

Solution

1. Step 1: Identify components involved in message delivery

   Notification service alerts users about new messages; if slow, users get delayed messages.

2. Step 2: Exclude unrelated causes

   Message storage speed does not cause delay in delivery; group management and profile pictures do not affect message delivery timing.

3. Final Answer:

   Notification service is slow or failing -> Option B

4. Quick Check:

   Delivery delay = notification issue [OK]

Hint: Delivery delays usually come from notification failures [OK]

Common Mistakes:

• Blaming message storage speed
• Thinking group size causes delay directly
• Ignoring notification service role

5. You are designing a scalable group messaging system for millions of users. Which approach best ensures message delivery without overloading servers?

hard

A. Send each message directly from sender to every recipient synchronously

B. Store messages only on sender's device and rely on manual forwarding

C. Use a message queue to asynchronously distribute messages to group members

D. Limit group size to 10 users to reduce load

Solution

1. Step 1: Understand scalability challenges

   Direct synchronous sending to many users overloads servers and causes delays.

2. Step 2: Identify scalable solution

   Using message queues allows asynchronous, reliable, and scalable message distribution without blocking sender or servers.

3. Step 3: Exclude impractical options

   Storing messages only on sender device or limiting group size reduces usability and scalability.

4. Final Answer:

   Use a message queue to asynchronously distribute messages to group members -> Option C

5. Quick Check:

   Scalable delivery = asynchronous queue [OK]

Hint: Use asynchronous queues for scalable message delivery [OK]

Common Mistakes:

• Trying synchronous delivery to all users
• Ignoring asynchronous processing benefits
• Reducing group size instead of scaling design