Design for Data That Takes Time to Retrieve

Performance & Reliability · import/export, loading, status

Updated 2026-08-04

Accept that not all stored data is immediately available. Older records are moved to cheaper storage that trades retrieval speed for cost, so some things exist but cannot be opened right now.
Mark archived items in the list rather than only on the way in. A user should know before they click that this one will take minutes and that one will not.
Turn retrieval into a request with a result, not a load with a spinner. Restore with a stated wait and a notification when ready is a task someone can walk away from.
Say how long, in the units that match reality. Minutes and hours are honest for archived retrieval, and a progress bar that cannot know its own duration is not.
Keep the metadata available even when the content is not. Titles, dates, sizes, and thumbnails should stay browsable so the archive is still searchable.
Explain the tiers where the user can choose between them:

Never let an automatic tiering rule surprise someone. If a project becomes slow to open after ninety days of inactivity, that rule belongs in the interface long before day ninety.
Batch what the user is likely to want together. Retrieving one file from an archived project and then another five minutes later is the pattern to design out.

Storage that is cheap to keep and slow to reach is a normal cost decision, and the interface is where it stops being a surprise.