Salient OA Interview Question: Recording Storage System

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
• 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

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

This is a storage-system design problem with TTL-aware records and multiple levels of metadata lookup. In Phase 1, you need path-based storage, retrieval, and copy semantics while correctly checking expiration. Phase 2 adds efficient ownership lookup by recording name, which usually requires a reverse index instead of scanning all records. Phase 3 introduces rollback and version history, so a robust solution must track state changes over time and recompute remaining TTLs from the original creation time. A practical implementation typically combines hash maps, reverse mappings, timestamp checks, and history snapshots or operation logs.