A team backs a worker's scratch directory with memory instead of disk — what does that speed cost them?

## What "memory-backed" actually means A scratch area can be declared with either of two backings. **Disk-backed** means the files live on the host's storage, like anything else the instance writes. **Memory-backed** means the area is a filesystem whose contents are held in memory: the process opens, writes and reads ordinary files at an ordinary path, and no block device is involved. The appeal is obvious. Unpacking an archive, writing intermediate frames, spooling a request body — all of it goes at memory speed, with no contention against whatever else on the host is using the disk. ## Where the bytes are charged The cost is not hidden, but it is easy to overlook: **those bytes are memory the workload is using.** The platform's accounting does not distinguish between memory a process allocated in code and memory occupied by files it wrote into a memory-backed area. Both are the workload's memory. Three consequences follow. - **The ceiling comes out of the memory budget.** A workload with a four-gigabyte memory budget and a two-gigabyte memory-backed scratch ceiling has, at worst, two gigabytes left for itself. If it was sized as though it had four, it is over budget the moment the scratch area fills. - **The failure looks like a memory problem, not a storage problem.** The team sees a workload apparently using far more memory than its code should, and starts hunting a leak in a process that is behaving perfectly. What the platform does to a workload that passes its memory ceiling is a separate subject, but the trigger here is files, not allocations. - **Spilling to disk is not a safety net you can assume.** Whether any of it can be written out under pressure depends entirely on how the host is configured, and container hosts are frequently configured with nowhere for that to go. ## What it does not change A memory-backed area is still **scratch**. It shares every lifetime property of the writable layer: | property | writable layer | memory-backed scratch | |---|---|---| | survives instance replacement | no | no | | private to one instance | yes | yes | | has an explicit ceiling | not by itself | yes, declared | | charged against memory budget | no | yes | | charged against host storage | yes | no | So choosing memory as the backing is a **speed-for-memory trade**, never a durability decision. Anyone reaching for it to keep files safe has misread the mechanism twice over. ## When it is the right call Memory-backed scratch earns its place when all of these hold: 1. The intermediate files are **small relative to the memory budget** and the ceiling fits comfortably beside the working set. 2. Their lifetime is **short** — created and deleted within one unit of work, so the high-water mark is bounded by concurrency and not by uptime. 3. The work is **I/O-bound on those files**, so removing the disk from the path is a real win rather than a rounding error. 4. There is a reason the bytes should not touch shared host storage at all — for example, material that should not persist on a machine even briefly. And it is the wrong call when file sizes are unpredictable, when the largest plausible input is a multiple of the memory budget, or when the workload is already memory-hungry. A disk-backed area with a generous ceiling fails on capacity in a way that is easy to read; a memory-backed area that is too small turns a storage sizing mistake into a memory incident. ## Sizing it in practice Size the memory budget as **working set plus scratch ceiling plus headroom**, and be explicit about all three when you write the spec down. Then make the worker delete intermediates as each unit of work completes, so the high-water mark is set by the number of jobs in flight rather than by how long the instance has been alive. If the honest ceiling does not fit inside a memory budget you can justify, that is the answer: the area belongs on disk. ## The interview point What this question really tests is whether you know that a filesystem can be a consumer of the memory budget. Engineers who have only thought of memory as "what my process allocates" declare a fast scratch area and are then surprised by a workload whose memory use has nothing to do with its code. Saying "those bytes are memory, so the ceiling comes out of the same budget" answers it in one line.