| Users/Requests | Disk Requests per Second | Queue Length | Response Time | Resource Usage |
|---|---|---|---|---|
| 100 requests/sec | 100 | Short queue | Low latency | Single disk, CPU low |
| 10,000 requests/sec | 10,000 | Medium queue | Moderate latency | Disk busy, CPU moderate |
| 1,000,000 requests/sec | 1,000,000 | Long queue | High latency | Disk saturated, CPU high |
| 100,000,000 requests/sec | 100,000,000 | Very long queue | Very high latency | Disk overloaded, CPU maxed |
Scheduling algorithm (SCAN, LOOK) in LLD - Scalability & System Analysis
Start learning this pattern below
Jump into concepts and practice - no test required
The disk I/O is the first bottleneck because SCAN and LOOK algorithms optimize disk head movement but cannot increase physical disk speed. As requests grow, the disk queue lengthens, causing delays.
- Horizontal scaling: Add more disks and distribute requests (e.g., RAID, sharding data across disks).
- Caching: Use memory caches to reduce disk reads for repeated data.
- Upgrade hardware: Use SSDs or faster disks to reduce seek time.
- Load balancing: Distribute requests evenly to avoid hotspots.
- Algorithm tuning: Use LOOK to reduce unnecessary disk head movement compared to SCAN.
At 10,000 requests/sec, disk I/O bandwidth and seek time become critical. Each request may require 5-10 ms seek time on HDDs, limiting throughput to ~100-200 requests/sec per disk.
To handle 1,000,000 requests/sec, thousands of disks or SSDs are needed, increasing cost significantly.
CPU usage grows with queue management and scheduling overhead but is usually less critical than disk I/O.
Start by explaining how SCAN and LOOK reduce disk head movement to improve throughput. Then discuss physical disk limits as bottlenecks. Finally, propose scaling solutions like adding disks, caching, and upgrading hardware.
Your disk handles 1000 requests/sec. Traffic grows 10x to 10,000 requests/sec. What do you do first?
Answer: Add more disks and distribute requests to reduce queue length and avoid disk saturation.
Practice
Solution
Step 1: Understand SCAN behavior
SCAN moves the disk head to the end of the disk in one direction, servicing requests along the way.Step 2: Understand LOOK behavior
LOOK moves the disk head only as far as the last request in the current direction, then reverses.Final Answer:
LOOK stops at the last request in the direction, SCAN goes to the disk edge -> Option CQuick Check:
LOOK stops early, SCAN goes to edge [OK]
- Confusing which algorithm stops at disk edge
- Thinking LOOK moves randomly
- Assuming SCAN moves only one way
Solution
Step 1: SCAN moves towards higher end first
Starting at 50, SCAN moves up servicing 70 and 90, then reaches disk edge 100.Step 2: SCAN reverses direction
After reaching 100, it moves down servicing 35, 20, and 10.Final Answer:
50 -> 70 -> 90 -> 100 -> 35 -> 20 -> 10 -> Option BQuick Check:
SCAN goes to edge 100 before reversing [OK]
- Not including disk edge in the path
- Reversing direction too early
- Skipping requests on the way
Solution
Step 1: LOOK moves towards higher requests first
Starting at 40, it services 70 and 90, stopping at last request 90.Step 2: LOOK reverses direction
Then it moves down servicing 35, 20, and 10, stopping at last request in that direction.Final Answer:
[40, 70, 90, 35, 20, 10] -> Option DQuick Check:
LOOK stops at last request, no disk edge [OK]
- Including disk edge in LOOK path
- Reversing direction too early
- Skipping requests on the way
requests = [20, 40, 60, 80]
head = 30
for track in range(head, 100):
if track in requests:
print(f"Servicing {track}")
for track in range(head-1, -1, -1):
if track in requests:
print(f"Servicing {track}")Solution
Step 1: Check range end in first loop
range(head, 100) goes from 30 to 99 (exclusive end), missing disk edge at 100.Step 2: Confirm disk convention
As per standard problems (disk size 100 includes edge 100), first loop should be range(head, 101) to reach 100.Final Answer:
The first loop should go to 101, not 100 -> Option AQuick Check:
range exclusive, edge 100 needs 101 [OK]
- Confusing inclusive vs exclusive range ends
- Starting second loop incorrectly
- Assuming head position is included twice
Solution
Step 1: Initial direction to lower tracks
Lower requests: 50, 10. Path: 100 -> 50 (50 tracks), 50 -> 10 (40 tracks). Subtotal: 90.Step 2: Reverse direction to higher tracks
Higher requests: 120, 180. Path: 10 -> 120 (110 tracks), 120 -> 180 (60 tracks). Subtotal: 170.Step 3: Total head movement
90 + 170 = 260 tracks.Final Answer:
260 tracks -> Option AQuick Check:
Sum of |current - next| over servicing sequence [OK]
- Including disk edges in LOOK movement
- Adding extra distances beyond last requests
- Misordering request servicing
