Split strategies (equal, exact, percentage) in LLD - Scalability & System Analysis

Scalability Analysis - Split strategies (equal, exact, percentage)

Growth Table: Split Strategies at Different Scales

Users	Equal Split	Exact Split	Percentage Split
100 users	Simple division, low overhead	Manual allocation manageable	Basic percentage calculations
10,000 users	Automated equal partitioning needed	Complex manual tracking, error-prone	Dynamic percentage adjustments required
1,000,000 users	Load balancing with hashing or consistent hashing	Exact splits become impractical, high coordination cost	Requires scalable percentage distribution algorithms
100,000,000 users	Distributed hashing, multi-level partitioning	Exact splits infeasible, system bottlenecks	Automated, approximate percentage splits with monitoring

First Bottleneck

The first bottleneck is the coordination and state management for exact split strategy. As user count grows, tracking and enforcing exact allocations requires heavy synchronization and data consistency, which slows down the system.

Scaling Solutions

• Equal Split: Use consistent hashing or range partitioning to distribute load evenly without central coordination.
• Exact Split: Avoid at large scale; if needed, use distributed consensus systems and strong coordination, but prefer approximate methods.
• Percentage Split: Implement dynamic load balancing with feedback loops and approximate percentage calculations to reduce overhead.
• Cache split decisions to reduce repeated calculations.
• Use horizontal scaling with stateless services to handle increased traffic.

Back-of-Envelope Cost Analysis

At 1 million users, assuming each user generates 1 request per second:

• Total requests per second: ~1,000,000 QPS
• Single server handles ~5,000 QPS → Need ~200 servers
• Storage for split state: Exact split requires large, consistent state storage; equal and percentage splits need less.
• Network bandwidth: 1 Gbps server can handle ~125 MB/s; plan accordingly for data transfer.

Interview Tip

Start by explaining each split strategy simply. Then discuss how each scales with users and traffic. Identify the bottleneck clearly. Propose practical scaling solutions matching the bottleneck. Use real numbers to support your reasoning.

Self Check

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

Answer: Add read replicas and implement caching to reduce load on the primary database before scaling application servers.

Key Result

Exact split strategy breaks first due to coordination overhead; prefer equal or percentage splits with hashing and caching for scalability.