| Users / Data Size | 100 Users | 10K Users | 1M Users | 100M Users |
|---|---|---|---|---|
| Read Requests per Second | ~100-500 | ~10K | ~1M | ~100M |
| Write Requests per Second | ~50-200 | ~5K | ~500K | ~50M |
| Data Size | GBs | TBs | PBs | Exabytes |
| Access Pattern | Mostly sequential, low concurrency | Mixed sequential and random, moderate concurrency | Highly random, high concurrency | Highly random, extreme concurrency, multi-region |
| Latency Sensitivity | Low to moderate | Moderate | High | Very high |
| Storage Type | Local disks or single DB | Distributed storage, caching introduced | Sharded DBs, SSDs, caching layers | Multi-region distributed storage, tiered storage |
Storage access patterns in HLD - Scalability & System Analysis
At small scale (100 users), storage access is simple and local disks or single database handle requests well.
At medium scale (10K-1M users), the first bottleneck is the storage I/O throughput and latency. Random access patterns cause disk seek delays and slow queries.
At large scale (100M users), the bottleneck shifts to storage system scalability and network bandwidth between distributed storage nodes.
- Caching: Use in-memory caches (Redis, Memcached) to reduce read load on storage.
- Sharding: Split data horizontally across multiple storage nodes to distribute load.
- Data Partitioning: Organize data by access patterns to optimize sequential reads and reduce random I/O.
- Tiered Storage: Use fast SSDs for hot data and slower disks for cold data.
- Replication: Use read replicas to scale read throughput and improve availability.
- CDN: For static content, use Content Delivery Networks to reduce storage access and latency.
- Compression and Compaction: Reduce storage size and improve I/O efficiency.
- Asynchronous Writes: Buffer writes to reduce write latency and batch operations.
Assuming 1M users with 1M read and 500K write requests per second:
- Storage IOPS needed: ~1.5 million per second (reads + writes)
- Network bandwidth: For 1KB average request size, ~1.5 GB/s (~12 Gbps)
- Storage capacity: Petabyte scale, depending on data retention
- Cache size: Tens to hundreds of GBs to hold hot data
- Number of storage nodes: Hundreds to thousands, depending on node capacity
When discussing storage access patterns scalability, start by describing the current access pattern (sequential vs random, read/write ratio).
Explain how these patterns affect storage I/O and latency.
Identify the bottleneck clearly (I/O throughput, latency, network).
Then propose targeted solutions like caching, sharding, replication, and tiered storage.
Always connect solutions to the specific bottleneck caused by access patterns.
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 considering sharding or hardware upgrades.
Practice
Solution
Step 1: Understand sequential access meaning
Sequential access means reading data in the exact order it is stored, one after another.Step 2: Compare with other patterns
Random access reads data in any order, batch access reads groups of data, streaming processes data continuously.Final Answer:
Sequential access -> Option AQuick Check:
Sequential = ordered reading [OK]
- Confusing random access with sequential
- Thinking batch means single item reading
- Mixing streaming with batch processing
Solution
Step 1: Define random access
Random access allows reading or writing data at any position without following a sequence.Step 2: Eliminate incorrect options
Batch access reads fixed-size groups, streaming is continuous flow, and discarding after one access is not random access.Final Answer:
Data can be read or written at any location without following order -> Option DQuick Check:
Random access = any location access [OK]
- Confusing batch with random access
- Thinking streaming means random access
- Assuming random access is sequential
Solution
Step 1: Identify processing style
The system reads 1000 entries at once, meaning it processes data in groups or batches.Step 2: Match with access patterns
Batch access means handling data in fixed-size groups, streaming is continuous single flow, random is unordered, sequential is one by one.Final Answer:
Batch access, because data is processed in groups -> Option CQuick Check:
Batch = group processing [OK]
- Confusing batch with streaming
- Assuming sequential means batch
- Thinking random access fits batch processing
Solution
Step 1: Understand streaming issues
Streaming requires managing data flow to avoid overload, called backpressure handling.Step 2: Identify cause of latency and loss
If backpressure is not handled, data can pile up causing delays and loss.Final Answer:
Not handling backpressure in the streaming pipeline -> Option AQuick Check:
Streaming needs backpressure control [OK]
- Confusing batch with streaming
- Ignoring backpressure importance
- Assuming random access causes streaming issues
Solution
Step 1: Analyze playback needs
Smooth playback requires continuous data flow, which is streaming access.Step 2: Analyze seeking needs
Jumping to any timestamp instantly requires random access to data at any position.Step 3: Combine patterns for best design
Use streaming for continuous playback and random access for quick seeking.Final Answer:
Streaming access for playback and random access for seeking -> Option BQuick Check:
Playback = streaming, seeking = random [OK]
- Using sequential for seeking which is slow
- Confusing batch with streaming for playback
- Ignoring random access need for seeking
Ready to prove it?
Pass the test and this pattern moves unknown
