| Users/Actions | Memory Usage | Undo Stack Size | Latency | Complexity |
|---|---|---|---|---|
| 100 users | Low (few commands stored) | Small (few undo steps) | Instant | Simple stack operations |
| 10,000 users | Moderate (more commands in memory) | Medium (longer undo history) | Still fast | Stack management with pruning |
| 1,000,000 users | High (large command history) | Large (may need limits) | Possible delay if not optimized | Need efficient storage and retrieval |
| 100,000,000 users | Very high (massive data) | Very large (undo history must be limited) | Latency noticeable without optimization | Requires distributed storage and pruning |
Command pattern for undo in LLD - Scalability & System Analysis
The undo stack storage becomes the first bottleneck as the number of users and commands grows. Storing every command and its state consumes memory and disk space. Also, retrieving and applying undo commands can slow down if the stack is too large or not efficiently managed.
- Limit Undo History: Keep only a fixed number of recent commands per user to reduce memory.
- Command Compression: Store commands in a compact form or only store deltas.
- Persistent Storage: Use databases or disk storage for older commands instead of memory.
- Sharding: Partition undo data by user or session to distribute load.
- Caching: Cache recent undo commands in memory for fast access.
- Asynchronous Processing: Perform heavy undo operations in background threads to avoid blocking.
Assuming each command object is ~1 KB:
- 100 users x 20 undo commands = 2 MB memory
- 10,000 users x 20 commands = 200 MB memory
- 1,000,000 users x 20 commands = 20 GB memory (likely needs disk storage)
- 100,000,000 users x 20 commands = 2 TB storage (requires distributed storage)
Request rate depends on user actions; each undo is a command execution. For 1M users with 1 action per second, system handles ~1M QPS, which requires horizontal scaling and efficient command processing.
Start by explaining the command pattern basics and how undo stacks work. Then discuss how scaling affects memory and latency. Identify the undo stack storage as the bottleneck. Propose limiting history, caching, and sharding as solutions. Use numbers to show understanding of resource needs. Finally, mention asynchronous processing to keep UI responsive.
Your undo stack database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?
Answer: Add read replicas and implement caching for recent undo commands to reduce database load. Also, consider limiting undo history size to reduce storage and processing.
