Design and implement a simplified recording storage service that manages audio/video recordings with time-to-live (TTL) functionality.
All operations should be supported as described below. Partial credit will be granted for each test passed, so you should run tests often and improve your solution incrementally. Do not change the existing method signatures.
Example structure:
[storage]
+- client123
| +- 2024-02-10
| | +- recording-a.mp4 (TTL: 7 days)
| | +- recording-b.wav (TTL: 30 days)
| +- 2024-02-09
| | +- recording-c.mp4 (TTL: 7 days)
+- client456
| +- 2024-02-10
| | +- recording-d.mp4 (TTL: 14 days)
Phase 1 — Initial Design & Basic Functions
STORE_RECORDING(client_id, recording_name, date, size, ttl_days)- Store the recording in the format
{client_id}/{date}/{recording_name} - Associate the specified TTL (in days) with the recording
- If a recording with the same path already exists, throw a runtime exception
- Store the recording in the format
GET_RECORDING(client_id, recording_name, date)- Return the recording metadata (size and remaining TTL) if it exists and has not expired
- Return nothing if the recording does not exist or has expired
COPY_RECORDING(source_path, dest_path)- Copy the recording to a new location, maintaining the original TTL
- If the source recording does not exist or has expired, throw a runtime exception
- If the destination already exists, overwrite the existing recording
Phase 2 — Recording Ownership & Metadata
GET_RECORDING_OWNERSHIP(recording_name)- Return a tuple containing
(client_id, date)for the given recording_name - Must handle cases where the recording ID does not exist (throw
RecordingNotFoundException) - Must handle cases where the recording exists but has expired (throw
ExpiredRecordingException) - The method should be efficient and not require scanning all clients/dates unnecessarily
- Should return consistent results even if the recording has been copied to multiple locations
- Return a tuple containing
Phase 3 — Version History & Rollback
ROLLBACK(timestamp)- Roll back the entire storage state to the specified timestamp
- Recalculate remaining TTLs based on the original creation date, not the rollback date
- Restore recordings that existed at that time but were later deleted
- Remove recordings that did not exist at that time but were later added
- Revert recordings to their specific version at that timestamp
- Maintain version history even after rollback
- Handle partial failures gracefully if some recordings cannot be rolled back
Language: Python 3
这道题是一个典型的带 TTL 的文件 / 录音存储系统设计题,核心在于同时维护“路径索引”和“业务元数据”。第一阶段需要支持按 <code>{client_id}/{date}/{recording_name}</code> 存储、查询和复制,并且在查询时正确判断是否过期;第二阶段要求能通过录音名快速反查所属客户端和日期,说明需要额外的反向索引,而不能每次全量扫描;第三阶段加入回滚和版本历史,重点是记录每次修改的状态变化,并在回滚时基于原始创建时间重新计算剩余 TTL。实现时通常会结合哈希表、索引映射、时间判断和历史快照 / 操作日志来完成。