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