Fine calculation in LLD - Scalability & System Analysis

Scalability Analysis - Fine calculation

Growth Table for Fine Calculation System

Users	Requests per Second (RPS)	Data Stored	System Changes
100 users	~10 RPS	Few KBs (fine rules, user data)	Single server, simple DB, no caching needed
10,000 users	~1,000 RPS	MBs (fine history, user profiles)	DB indexing, caching layer, load balancer
1,000,000 users	~50,000 RPS	GBs (fine records, audit logs)	DB read replicas, sharding, distributed cache, multiple app servers
100,000,000 users	~5,000,000 RPS	TBs (long term storage, analytics)	Microservices, global CDN, data partitioning, asynchronous processing

First Bottleneck

At small scale, the database is the first bottleneck because it handles all fine calculation queries and updates. As users grow, the DB CPU and I/O get saturated.

At medium scale, application servers CPU and memory become bottlenecks due to complex fine calculation logic and concurrent requests.

At large scale, network bandwidth and data storage become bottlenecks because of heavy data transfer and large fine history storage.

Scaling Solutions

• Database: Use read replicas to spread read load, connection pooling to manage DB connections, and sharding to split data by user region or ID.
• Caching: Cache frequent fine rules and recent fine calculations in Redis or Memcached to reduce DB hits.
• Application Servers: Horizontally scale by adding more servers behind a load balancer.
• Data Storage: Archive old fine records to cheaper storage to reduce DB size.
• Network: Use CDNs for static content and asynchronous processing for heavy calculations to reduce latency.

Back-of-Envelope Cost Analysis

• At 10,000 users: ~1,000 RPS, DB handles ~1,000 QPS, fits in a single PostgreSQL instance with caching.
• At 1,000,000 users: ~50,000 RPS, need ~5 app servers (each 10,000 RPS), DB read replicas to handle 50,000 QPS.
• Storage: Each fine record ~1 KB, 1M users with 10 fines each = ~10 GB data.
• Bandwidth: 50,000 RPS * 1 KB = ~50 MB/s, fits in 1 Gbps network link.

Interview Tip

Start by estimating user growth and request rates. Identify the first bottleneck (usually DB). Discuss scaling DB with replicas and caching. Then cover app server scaling and data partitioning. Finally, mention cost and latency trade-offs.

Self Check Question

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

Answer: Add read replicas and implement caching to reduce DB load before scaling app servers, because the DB is the first bottleneck.

Key Result

The database is the first bottleneck as user requests grow; scaling requires read replicas, caching, and sharding before adding more app servers.