An in-memory LRU cache budgets its entries with unsafe.Sizeof and the process is OOM-killed in production; what went wrong and how do you fix the accounting?

## What the budget actually measured `unsafe.Sizeof` is a compile-time constant describing the value's own representation. For an entry like ```go type entry struct { key string // 16: pointer + length data []byte // 24: pointer + length + capacity meta map[string]string // 8: one pointer } ``` it is 48 bytes on a 64-bit platform and stays 48 forever. Every field is a handle; none of the memory they refer to is inside the struct. So a cache that adds `unsafe.Sizeof(e)` to a running total on insert is counting the *bookkeeping* and ignoring the *payload*. With one-megabyte payloads the model is wrong by a factor of about twenty thousand, which is why the limit never triggered and the kernel's OOM killer had the last word. A related trap makes it worse: the number is a compile-time constant, so it is also the number a reviewer sees and believes. Nothing at run time can contradict it. ## Building an honest size function A deep size is written by hand, term by term: ```go func size(e entry) int { n := int(unsafe.Sizeof(e)) n += len(e.key) // the string's backing bytes n += cap(e.data) // the whole backing array, not just the used part for k, v := range e.meta { n += len(k) + len(v) + int(unsafe.Sizeof(""))*2 } return n } ``` Three judgment calls are hiding in there. **Capacity, not length.** A slice keeps its entire backing array alive, and a slice grown by `append` usually carries spare capacity beyond its length. Charging `len` understates what the entry pins. **Maps cannot be derived.** A map's runtime hash table allocates room for more slots than it currently holds, and the per-entry overhead is an implementation detail that changes between releases. Estimate it from measurement and mark the estimate as such. **Allocator rounding is real.** The runtime rounds each allocation up to a size class, so a 33-byte key does not cost 33 bytes. For a cache holding millions of small entries this alone can be a double-digit percentage. The conclusion most teams reach is that the arithmetic should be calibrated, not trusted: run a representative workload, take a heap profile at steady state, and compare the accounted total with what the profile says. A stable ratio means the model is usable with a safety factor; a growing gap means something is unaccounted. ## Stopping the model from drifting The failure that brought the service down is not really the wrong formula — it is that nothing connects the formula to the struct. Someone adds a field, the size function is not updated, and the budget quietly becomes fiction again. Because `unsafe.Sizeof` is a compile-time constant, you can wire the two together and let the compiler enforce it: ```go // The build fails if entry stops being 48 bytes. var _ [unsafe.Sizeof(entry{}) - 48]byte var _ [48 - unsafe.Sizeof(entry{})]byte ``` Both declarations are needed. If the struct grows, the first is a legal positive length but the second is a negative constant that cannot be represented as `uintptr`, and the build stops. If it shrinks, the roles swap. A comment next to the pair pointing at the size function tells the next person exactly what to update. This is the honest use of the whole family: not measuring memory, but pinning a layout so that a change announces itself at build time instead of at 3am. ## What else to change - **Bound by something you can measure.** Counting entries and enforcing an entry-count limit, tuned by observed heap usage, is often more robust than a byte model, particularly when values vary in size by orders of magnitude. - **Give the runtime a backstop.** A soft memory limit lets the collector push back before the kernel intervenes, turning a hard kill into degraded performance you can alert on. - **Alert on the gap, not just the total.** Export both the accounted total and the measured heap size; the ratio between them is the health of your model, and it is the metric that will warn you the next time a struct changes. ## The summary line for an interview Sizeof told the truth about the struct and nothing about the data. A memory budget needs a runtime measurement of what the pointers reach, calibrated against a heap profile, and a compile-time assertion so the struct cannot change underneath it.