Board, Player, Game classes in LLD - Scalability & System Analysis

Scalability Analysis - Board, Player, Game classes

Growth Table: Board, Player, Game Classes

Scale	Users / Games	Data Size	Server Load	Latency	Notes
100 users	~50 concurrent games	Small in-memory state	Single server handles all	Low latency	Simple in-memory objects, no persistence needed
10,000 users	~5,000 concurrent games	Moderate memory, some persistence	Multiple servers, load balancing	Low to moderate latency	Need database for game state, player profiles
1,000,000 users	~500,000 concurrent games	Large data, distributed storage	Horizontal scaling, caching	Moderate latency	Sharding game data, caching hot games
100,000,000 users	~50,000,000 concurrent games	Very large data, multi-region	Global load balancing, CDN	Low latency via edge	Complex partitioning, eventual consistency

First Bottleneck

At small scale, the in-memory game state works fine. As users grow to thousands, the database storing player and game data becomes the first bottleneck. It struggles with many read/write requests per second. This slows down game updates and player actions.

Scaling Solutions

• Database scaling: Add read replicas to handle more queries. Use connection pooling to reduce overhead.
• Caching: Cache frequently accessed game states and player info in memory (e.g., Redis) to reduce DB load.
• Horizontal scaling: Add more application servers behind a load balancer to handle more concurrent games and players.
• Sharding: Partition game and player data by user ID or game ID to distribute load across multiple databases.
• CDN and edge computing: For very large scale, use CDN to serve static assets and edge servers to reduce latency.

Back-of-Envelope Cost Analysis

• At 10,000 users with 5,000 concurrent games, assuming 1 action per second per game: 5,000 QPS to database.
• Single PostgreSQL instance handles ~5,000 QPS, so near capacity.
• Memory per game state ~10 KB, total ~50 MB for 5,000 games in memory.
• Network bandwidth: 5,000 QPS * 1 KB per request = ~5 MB/s, well within 1 Gbps link.

Interview Tip

Start by describing the components: Board, Player, Game classes and their responsibilities. Then discuss how data grows with users and games. Identify the first bottleneck (usually database). Propose clear, stepwise scaling solutions like caching, read replicas, and sharding. Use numbers to justify your choices. Keep answers structured and focused.

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 load on the primary database before considering sharding or more complex solutions.

Key Result

The database is the first bottleneck as user and game counts grow; scaling requires caching, read replicas, and sharding to maintain performance.