Going, going, gone: best practices for deleting your assets

Deleting digital files is tricky business: on one hand, it feels important to stay organized, maintain data integrity, and cut costs by reducing storage. On the other hand, once your files are gone, they're gone. No redos. That's it. Hopefully you really meant to delete that video.

In the current economic environment, many organizations are looking for new cost-optimization methods. This is an understandable position and is definitely something our team considers when thinking about how to price our products, as most recently manifested in new volume discounts.

While deleting assets may reduce the storage portion of a Mux bill, this approach also impacts your (and our) ability to troubleshoot potential issues and removes end user access to videos.

We empower our DELETE endpoint to really mean “delete,” and we generally aren’t able to recover deleted items.

So, how should you navigate these treacherous waters? Our asset delete API is a delicate tool to provide directly to end users, but we have some options for you to consider:

Delay and batch-process destructive actions

Otherwise known as a “soft delete.” In this implementation, instead of directly using our delete API, you can mark assets for deletion in the application. Make a list of all items that are scheduled to be deleted, remove all references from the frontend UI, and then (within our rate limits) delete the assets after a predetermined expiration period.

Let’s assume Acme Company’s end users are currently allowed to delete assets. When they remove an item, that action triggers a function that directly accesses our delete API. Here’s how to switch to the soft delete option:

1. Create a database table that will store a list of deleted assets with their associated asset IDs and expiration times.
2. Update the function exposed to customers: When end users click “delete,” the asset is flagged as deleted in an assets table and removed from their view-list of videos.
3. Log the asset_id, expiration_date, and deleted_by_user_id in the deleted_assets database table.
4. Create a scheduled process that will query the database and select rows that have an expiration_date before the task initiation date.
5. Run the function from step 4 every week/month/quarter according to business needs.

For reference, storing a one-hour video in Mux for one week costs just under $0.05 USD — and becomes cheaper with volume discounts.

Move your assets to cold storage

This can function as an independent process or fit into the batch-and-delay model. In this scenario, assets are backed up to external object storage.

1. When a “delete” request is submitted for an asset, add master_access and record the necessary information in a database, including the original asset ID and playback ID(s).
2. After receiving the video.asset.master.ready webhook, use the master URL (valid for 24 hours) to add the video to your preferred storage location.
3. Wait one week/month/quarter.
4. Delete the assets from Mux Video on the expiration_date in the database, while keeping them saved separately in cold storage.

A single part range request may be used to determine the size of the master file with curl "MASTER_URL" -i -H "Range: bytes=0-1023". Comparing the response from this request with the file size of your downloaded copy can help verify whether the file was completely received.

Use test streams and assets

When testing our products during early-stage development, consider using the test parameter.

Test streams and their resulting assets are free and will be automatically removed from your environment after 24 hours. There are some guardrails in place when using test resources:

• Assets are limited to a 10-second duration
• Live streams are limited to a 5-minute duration

Don’t delete assets

My final suggestion: Don’t delete assets! Removing the end user’s ability to directly delete videos is a great first step, but if access to assets is a priority, leaving them in Mux Video is the most direct method.

Keep in mind that assets cannot be retrieved after deleting them. If this isn’t a power you’re confident will be wielded carefully within your (or your customers’) organization, it might be better to eliminate the feature altogether.

Some customers encounter situations that require support, both from their internal organization and from Mux. Other customers prefer to have the original data included with an asset when it is created. Any processes dependent on accessing asset information get more complex if the original data isn’t there because it was deleted.

Additionally, managing the mapping between an original asset, the asset’s details post-deletion, and any future iterations of new assets created from externally-hosted videos can create tricky synchronization cases between different systems. If the original asset isn’t deleted, this complexity is avoided entirely.

I hope these options add more context to our services and prove useful in your endeavors. As always, if you have questions or feedback, please reach out to us at https://mux.com/support.