PATTERN Cited by 1 source

ReadPlan metadata cache

Pattern

Separate metadata resolution (path → storage address mapping) from data fetch; cache the resolved ReadPlan in a distributed memory store for sub-2 ms access on repeated reads.

Problem

Even with a unified metadata schema achieving O(1) lookups, hot BLOBs accessed concurrently by hundreds of GPUs create metadata hot-shard problems. Every concurrent reader hitting the same metadata path creates load concentration.

Solution

Cache the ReadPlan — the resolved mapping from object path to (blockId, offset, size) tuples — in a distributed-memory store (similar to memcache). Subsequent reads of the same BLOB skip the metadata lookup entirely and go straight to data fetch.

Result at Meta

• 1–2 ms metadata access for cached ReadPlans
• Solves the metadata hot-shard problem
• Improves p50 and p99 latencies by serving from memory
• Combined with the distributed data cache, absorbs traffic spikes from GPU restarts and checkpoint loading

(Source: sources/2026-07-01-meta-ai-storage-blueprint-at-scale)

Seen in

• sources/2026-07-01-meta-ai-storage-blueprint-at-scale — Meta AI storage spikes and hot spots