Design LinkedIn Messaging

LinkedIn's "Design LinkedIn Messaging" is a common system design interview question focusing on building a scalable, real-time messaging platform. It typically emphasizes backend architecture, real-time delivery, data engineering for storage/retrieval, and support for web/mobile clients.[1][2]

Problem Statement

Design a messaging system for LinkedIn that supports real-time one-to-one and group conversations (InMail and chat), similar to LinkedIn's production system. The system must handle high-volume messaging (billions of messages daily), ensure low-latency delivery (<200ms), provide read receipts/typing indicators, support search/threading, and scale for 1B+ users with features like offline queuing and cross-device sync. Key challenges include message ordering, eventual consistency, sharding, and failover across datacenters.[3][1]

Functional Requirements

• Send/receive text messages in 1:1 or group chats (up to N participants).
• Real-time delivery with online/offline status, last seen, delivery/read receipts.
• Message search, threading, and pagination (infinite scroll).
• Typing indicators and message editing/deletion.
• Support for attachments (images/files, limited).[2][1][3]

Non-Functional Requirements & Constraints

• Scale: 1B+ users, 100M+ daily active, peak 1M messages/sec; store petabytes of data.
• Latency: <200ms for reads/sends; high availability (99.99% uptime).
• Consistency: Eventual for delivery; strict ordering per conversation.
• Storage: NoSQL (e.g., DynamoDB/Cassandra) with sharding by user/conversation ID; single message copy per thread to optimize space.[1][2][3]
• Traffic: Assume 5-10 reads per write; mobile/web clients via APIs/WebSockets.
• Edge cases: Offline delivery, retries, spam filtering, data retention (e.g., 1 year).[2]

Core APIs (Inputs/Outputs)

| API | Input Example | Output Example | Notes | |-----|---------------|----------------|-------| | SendMessage | {senderId: 123, convoId: "abc", content: "Hello", timestamp: 1640000000} | {messageId: "msg1", status: "sent"} | Async delivery; returns ACK.[2] | | FetchMessages | {convoId: "abc", limit: 50, afterId: "msg50"} | [{messageId: "msg1", senderId: 123, content: "Hello", status: "delivered"}] | Paginated, ordered by timestamp.[2] | | MarkAsRead | {convoId: "abc", lastReadId: "msg100"} | {updated: true} | Updates receipts for participants.[1] | | GetUnreadCount | {userId: 123} | {convoId: "abc": 5, total: 20} | Aggregated across inboxes.[3]

No full official LinkedIn problem statement with exact I/O examples exists publicly; interview versions vary but follow this structure from prep guides and LinkedIn's engineering blogs.[3][1]