Entry and exit flow in LLD - Scalability & System Analysis

Scalability Analysis - Entry and exit flow

Growth Table: Entry and Exit Flow

Users	Entry Requests/sec	Exit Requests/sec	System Components Impacted	Notes
100	~10	~10	Single server handles all flows	Simple synchronous processing
10,000	~1,000	~1,000	App server CPU load increases, DB handles more writes	Need load balancing and caching
1,000,000	~100,000	~100,000	Database becomes bottleneck, network bandwidth stressed	Introduce sharding, async processing, CDN for static content
100,000,000	~10,000,000	~10,000,000	Multiple data centers, global load balancing, complex partitioning	Microservices, event-driven architecture, advanced caching

First Bottleneck

At low scale, the application server CPU and memory handle entry and exit flows easily. As users grow to thousands, the database becomes the first bottleneck because it must process many writes and reads for entry and exit events. The database's limited query per second (QPS) capacity causes delays. Network bandwidth and server CPU become bottlenecks only at very large scale.

Scaling Solutions

• Horizontal Scaling: Add more application servers behind a load balancer to handle increased entry and exit requests.
• Database Read Replicas: Use read replicas to offload read queries from the primary database.
• Caching: Cache frequent queries or session data to reduce database load.
• Sharding: Partition the database by user or region to distribute load.
• Asynchronous Processing: Use message queues to handle entry and exit events asynchronously, smoothing spikes.
• CDN: For static content related to entry/exit flows, use CDN to reduce server load.

Back-of-Envelope Cost Analysis

• At 10,000 users with 1,000 requests/sec, expect ~80 GB/day of log data storage for entry/exit events.
• Network bandwidth at 1,000 requests/sec with 1 KB payload ≈ 1 MB/s (8 Mbps), manageable on 1 Gbps link.
• Database QPS limit ~5,000; above this, need replicas or sharding.
• Each app server can handle ~2,000 concurrent connections; scale servers accordingly.

Interview Tip

Start by describing the flow of entry and exit requests through the system. Identify the components involved and their capacity limits. Discuss how load increases affect each component. Then propose scaling solutions step-by-step, explaining why each is needed. Use real numbers to support your reasoning.

Self Check

Your database handles 1,000 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

Entry and exit flow systems scale well initially but face database bottlenecks at medium scale; adding replicas, caching, and sharding are key to handle growth.