Media sharing in messages in HLD - Scalability & System Analysis

Scalability Analysis - Media sharing in messages

Growth Table: Media Sharing in Messages

Scale	Users	Messages/Day	Media Uploads/Day	Storage Needed	Bandwidth	System Changes
Small	100	10,000	2,000	~20 GB	~50 Mbps	Single server, local storage, simple DB
Medium	10,000	1,000,000	200,000	~2 TB	~500 Mbps	Multiple app servers, CDN for media, DB replicas
Large	1,000,000	100,000,000	20,000,000	~200 TB	~5 Gbps	Sharded DB, distributed storage, multi-CDN, load balancers
Very Large	100,000,000	10,000,000,000	2,000,000,000	~20 PB	~50 Gbps+	Global data centers, advanced sharding, tiered storage, edge caching

First Bottleneck

At small to medium scale, the database becomes the first bottleneck due to high write and read operations for message metadata and media references.

As user count and media volume grow, storage I/O and network bandwidth for media uploads/downloads become bottlenecks.

Eventually, the media storage system and CDN capacity limit scalability before the app servers.

Scaling Solutions

• Database: Use read replicas and connection pooling to handle increased queries.
• Caching: Cache frequently accessed media metadata and message data to reduce DB load.
• Storage: Move media files to distributed object storage (e.g., S3) with lifecycle policies.
• CDN: Use Content Delivery Networks to serve media closer to users, reducing bandwidth and latency.
• Sharding: Partition database and storage by user or message ID to distribute load.
• Horizontal Scaling: Add more app servers behind load balancers to handle concurrent connections.
• Compression & Thumbnails: Store optimized media versions to save bandwidth and storage.

Back-of-Envelope Cost Analysis

Assuming 1 million users sending 100 messages/day with 20% containing media:

• Messages/day: 100 million
• Media uploads/day: 20 million
• Average media size: 1 MB -> 20 TB/day storage inflow
• Bandwidth: 20 million uploads + downloads -> ~5 Gbps sustained
• DB QPS: ~10,000 queries per second (writes + reads)
• Storage growth: 20 TB/day -> requires tiered storage and archival

Interview Tip

Start by defining scale milestones and expected traffic.

Identify the first bottleneck clearly (usually DB or storage).

Discuss incremental scaling steps: caching, read replicas, CDN, sharding.

Explain trade-offs and how each solution addresses specific bottlenecks.

Keep answers structured: current state, bottleneck, solution, future growth.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and implement caching to reduce direct DB load before scaling vertically or sharding.

Key Result

Media sharing systems first hit database bottlenecks at moderate scale, then storage and bandwidth limits at large scale; solutions include caching, read replicas, CDN, sharded storage, and horizontal scaling.