Rating and review system in LLD - Scalability & System Analysis

Scalability Analysis - Rating and review system

Growth Table: Rating and Review System

Scale	Users	Reviews per day	Storage	Traffic	System Changes
Small	100	500	~10 MB	Low	Single app server, single DB instance
Medium	10,000	50,000	~1 GB	Moderate	DB read replicas, caching, load balancer
Large	1,000,000	5,000,000	~100 GB	High	Sharded DB, CDN for images, distributed cache
Very Large	100,000,000	500,000,000	~10 TB	Very High	Multi-region deployment, microservices, advanced sharding

First Bottleneck

At small to medium scale, the database is the first bottleneck because it must handle many read and write queries for reviews and ratings. Writes increase with new reviews, and reads increase with users fetching reviews. The DB CPU and disk I/O limit throughput.

Scaling Solutions

• Database Read Replicas: Offload read queries to replicas to reduce load on primary DB.
• Caching: Use in-memory caches (e.g., Redis) for frequently read data like average ratings.
• Horizontal Scaling: Add more application servers behind a load balancer to handle more user requests.
• Sharding: Partition the database by product or user ID to distribute write and read load.
• CDN: Serve review images and static content via CDN to reduce bandwidth and latency.
• Asynchronous Processing: Use message queues to handle heavy write operations asynchronously.

Back-of-Envelope Cost Analysis

• Requests per second (RPS): At 1M users, assuming 5M reviews/day -> ~60 reviews/sec write + ~6000 reads/sec (assuming 100 reads per review) = ~6060 RPS total.
• Storage: Average review size ~2 KB (text + metadata). 5M reviews/day -> 10 GB/day. For 10 days retention -> ~100 GB storage.
• Bandwidth: Assuming 100 KB per review fetch (including images), 6000 reads/sec -> ~600 MB/s (~4.8 Gbps). Requires CDN and network scaling.

Interview Tip

Start by clarifying scale and usage patterns. Identify bottlenecks step-by-step: database, app servers, network. Propose solutions matching bottlenecks: caching for reads, sharding for writes, CDN for media. Discuss trade-offs and monitoring strategies.

Self Check

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

Answer: Add read replicas to offload read queries and implement caching to reduce DB load before considering sharding or adding more app servers.

Key Result

The database becomes the first bottleneck as user and review volume grows; scaling requires read replicas, caching, and sharding to maintain performance.