Why unused data is hard to delete
When a product is shut down, deleting its data is rarely a simple matter of dropping a few tables. Products depend on shared infrastructure, and data assets are often referenced by code and other systems that remain active. Meta’s Systematic Code and Asset Removal Framework (SCARF) includes a subsystem that automates the identification and removal of unused data types, avoiding tedious manual work and ensuring data is consistently cleaned up when products are deprecated.
SCARF tracks classes of data — database tables, partitioned "use cases" in shared storage systems, object classes — rather than individual records. Deleting individual rows and objects is handled by a separate system, DELF. For each supported data system, SCARF coordinates metadata collection (e.g., data quantity, field types), usage collection, analysis, and actions. Common components are standardized across systems, though implementations are system-specific.
Determining whether data is actually used
SCARF uses two signals to decide whether deletion is safe: static code analysis and runtime traffic measurement. Statically, SCARF queries Glean, which exposes compiler-extracted facts in an indexed format, to find code that appears to reference a given data type. For example, data types in Meta’s TAO graph database are each referenced by enum values, and SCARF locates usages of those values across multiple languages.
viewed_photo = TAO.fetch(
id=objectId,
type=TAOType.USER_VIEWED_PHOTO,
)
At runtime, Meta’s data systems publish counters showing how many reads each data type receives from production traffic, while excluding traffic from backup infrastructure. Instrumenting systems that serve billions of requests per second introduces real engineering constraints — SCARF has to count usage without causing performance degradation.
The deletion pipeline
When SCARF determines that a data type is unused, it notifies the responsible engineering team through an internal ticket. The system does not wait for acknowledgement; it biases toward automatic removal, relying on its analysis to ensure only unused data is deleted. Waiting for manual approval would not scale to the volume of assets SCARF processes.
After a configured waiting period, SCARF blocks all reads and writes using a mechanism specific to the data system. This acts as a dry run for actual deletion. If no problems surface during this access-restriction window, the data is deleted. For instance, SCARF would instruct TAO to raise errors on any read or write attempts to an unused data type, then, after further monitoring, to delete the data.
The access restriction period serves as a buffer: mistakes can be caught before any deletion occurs, and analysis can be updated to account for missing signals. If data is deleted erroneously, backups at Meta provide a final safeguard. Engineers can also influence the process — overriding usage signals they believe are false positives, accelerating the timeline, or reporting bugs in SCARF’s analysis back to its maintainers.
Handling dependencies across systems
Meta stores data in many specialized systems. A single product may use TAO for graph queries and another system for analytics, with pipelines moving data between them. Given these interconnections, SCARF must understand when data must be removed from multiple places, and in what order.
SCARF models these relationships through a curated set of generated asset dependencies. For each asset and its inbound and outbound dependencies, SCARF determines which asset must be deleted first and whether deleting one requires deleting another. Some assets exist solely because data is moved between systems and must be removed together in a multi-step process. This prevents SCARF from deleting assets out of order.
References in code also constrain deletion. SCARF will not remove data if it finds code that could use it, even if that code never runs — it does not break edges in the dependency graph between code and data. A debug script referencing a data type, for example, will block deletion. SCARF’s dead code subsystem helps here by removing the unused script, after which the data type can be cleaned up.
Scale and cadence
SCARF’s removal work carries real cost savings. Over the past year it removed petabytes of unused data across 12.8 million data types stored in 21 different data systems. The system runs daily because new data types are created and abandoned continuously; running regularly lets SCARF act as soon as the final references to an asset disappear.
The subsystem operates concurrently on millions of assets each day, reducing the need for manual cleanup. Its maintenance team works closely with the teams that build Meta’s data systems to develop the APIs SCARF uses to restrict access and eventually delete data. The broader SCARF framework also provides workflow tooling for human-led deprecation projects and gives privacy teams visibility into the progress of ongoing product deprecations, with guidance tailored to the specific code and data being removed.
