A team runs one in-memory store for several jobs - what four roles can it fill, and which one is a cache?

## One component, four different jobs An **in-memory store** is a separate piece of software that answers from memory rather than from disk. It holds **entries**: a `key`, which is the address, and a `value`, which is the payload. Teams reach for one for very different reasons and then talk about all of them as though they were a single thing called "the cache". They are four distinct roles, and the difference is not a matter of vocabulary. The role decides what must survive a restart, what an entry's deadline means, how much memory the tier has to be given, and what it means for the callers when the tier is empty or unreachable. ## Role one - a derived copy The store holds a faster copy of data that a **system of record** still holds and is still authoritative for. This is the only one of the four roles that is a cache. - Losing an entry costs **time, not information**: the caller asks the system of record and gets the same answer more slowly. - Because that is true, the tier can be sized to the hot subset rather than the whole dataset, and entries may be reclaimed under memory pressure. - An entry's deadline here is a **freshness bound** - a statement about how stale a copy may get, chosen by the design. Everything about designing such a cache at scale - its layers, its write strategies, when an entry must be invalidated, what happens when many callers miss at once - is a separate subject with its own owners. Naming the role is what this question is about. ## Role two - the sole home for ephemeral state The store holds facts that are created here and held nowhere else. There is nothing behind the entry to ask. - Losing an entry **loses the fact**. There is no slower path to the same answer, because there is no other holder. - The entry's deadline is not a freshness bound; it is the thing itself, part of what the system promises. - Sizing is the whole live population plus headroom, not a hot subset, because an entry that is not held is not merely a slower read. ## Role three - a coordination point Several processes need to agree on who holds something, and they agree by consulting one shared place. What is stored is tiny - a marker that a claim is taken, and by whom, usually with a deadline so a process that dies does not hold it forever. The failure that matters is not slowness. It is **two processes both believing they hold the same thing**, or every process unable to proceed. How such an agreement is made correct, and what guarantees it can honestly rest on, is a distributed-systems subject in its own right; the point here is that a design asking for this is not asking for a cache. ## Role four - a transient transport The store delivers something to whoever is connected at that moment and keeps nothing for whoever is not. A listener that was disconnected does not receive it - that is the definition of the role, not a defect in it. This is the role most often chosen by accident. If anyone must receive the item later, acknowledge it, or replay it, the design has left this role: it wants a retained log, which is a different component and a different subject. ## What the role decides | Role | Is it a cache? | What losing an entry means | What sizing follows | |---|---|---|---| | Derived copy | Yes | A slower read from the system of record | The hot subset; more misses if undersized | | Sole home for ephemeral state | No | The fact is gone | The whole live population, with headroom | | Coordination point | No | Two holders, or nobody able to proceed | Tiny, but it must always be reachable | | Transient transport | No | Whoever was not listening never hears it | Small at rest; a slow listener can accumulate | ## Not every store fills all four Stores in this class differ in what they actually offer. Some have no mechanism for delivering anything to listeners at all, so role four does not exist there. Some keep nothing across a restart by design, which makes them a poor home for state that has no other holder, while others offer restart survival as a posture you choose. Some reclaim entries when memory runs short; others refuse further writes instead - and which of those you want is decided by the role, not by taste. That is why the useful order is: name the role, then pick the store. One deployment can carry more than one role, and most real ones do. The discipline that matters is writing down which entries are in which role, because the strictest role present ends up dictating the settings under which all of them run.