Transaction history in LLD - Scalability & System Analysis

Scalability Analysis - Transaction history

Growth Table: Transaction History System

Users	Transactions/day	Data Size	System Changes
100	1,000	~10 MB	Single server, simple DB, no caching needed
10,000	100,000	~1 GB	DB indexing, read replicas, basic caching
1,000,000	10,000,000	~100 GB	Sharded DB, distributed cache, horizontal app scaling
100,000,000	1,000,000,000	~10 TB	Multi-region sharding, archival storage, CDN for UI data

First Bottleneck

The database is the first bottleneck as transaction volume grows. It struggles with write throughput and query latency because transaction history requires frequent writes and complex queries for user statements.

Scaling Solutions

• Read Replicas: Offload read queries to replicas to reduce load on primary DB.
• Caching: Use in-memory caches (e.g., Redis) for recent or frequent queries.
• Sharding: Split data by user ID or time range to distribute load across multiple DB instances.
• Horizontal Scaling: Add more application servers behind load balancers to handle increased traffic.
• Archival Storage: Move old transactions to cheaper, slower storage to keep main DB performant.
• CDN: Use for static UI assets and possibly precomputed reports to reduce server load.

Back-of-Envelope Cost Analysis

• At 1M users with 10 transactions/day: 10M writes/day ≈ 115 writes/sec.
• Database must handle ~200 QPS (including reads).
• Storage: 100 GB for transaction data (assuming 10 KB per transaction).
• Network bandwidth: ~10 MB/s for data transfer (reads + writes).
• One DB instance can handle ~5,000 QPS, so single DB can handle writes but reads require replicas.

Interview Tip

Start by estimating user and transaction volume. Identify the bottleneck (usually DB). Discuss scaling steps in order: caching, read replicas, sharding, horizontal app scaling. Mention trade-offs like consistency and latency. Use real numbers to justify choices.

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 adding more app servers.

Key Result

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