You run one in-memory tier shared by a dozen teams; what bounds one tenant's mistake, and when do you split it?

## The three rungs The question sounds like a choice and is really a ladder: each rung needs the one below it, and only the top one is isolation. | Rung | What it bounds | What it costs | What it misses | |---|---|---|---| | **Accounting** - per-owner rollup of usage | Nothing | A periodic sampling pass off the serving path, and a convention everyone keeps | A tenant that is slow rather than large; anything happening right now | | **Quota** - admission by owner on the path in | Size and rate, per owner, where the path is enforced | A proxy hop and a new failure domain, or a bypassable library | Anyone who connects directly; damage from a single legal operation | | **Separation** - a separate instance per tenant | The blast radius itself: ceiling, capacity and keyspace are the tenant's own | Utilisation, since each instance needs its own headroom; more to operate and upgrade | Nothing about isolation; it is the honest answer, at a price | ## Accounting: necessary, and not a bound Rolled-up usage per owner turns anonymous growth into someone's growth. That is worth real money in behaviour change and in incident response, and it is the precondition for everything above it: **a quota you cannot measure per owner cannot be applied**. But it is a report. It arrives after the fact, it says nothing about latency imposed on neighbours, and it depends entirely on a naming convention that one team can quietly opt out of. Anybody who offers accounting as the answer to 'what stops team A from hurting team B' has answered a different question. ## Quotas: enforcement the platform has to build Most stores of this class enforce nothing per owner, so the quota has to live on the path in - in a shared client library, or in a proxy every tenant must traverse. Design decisions that matter: - **Pick a measurable dimension.** Approximate bytes per owner, entry count per owner, or write rate per owner. Each catches a different failure, and bytes is the one that is hardest to measure cheaply. - **Decide what exceeding it does.** Refusing that owner's writes while its neighbours keep serving is the whole point; anything softer is a dashboard. - **Accept the bypass.** A library is advisory - anyone can open a connection directly - so a library quota is a guard against accident, not against intent. A proxy is enforceable and is a new hop, a new thing to scale, and a new way for the tier to be down. - **Know what it does not catch.** A tenant within its size and rate allowance can still issue one operation expensive enough to hurt everyone. Quotas bound volume, not cost per call. ## Separation: the rung that actually holds A separate instance gives a tenant its own ceiling, its own capacity, its own keyspace and its own restart schedule. It is the only arrangement in which the honest answer to 'what can my neighbour do to me' is 'nothing', and the answer is not free: each instance carries its own headroom so total utilisation falls, and the number of things to monitor, upgrade and fail over multiplies. Triggers that should move a tenant onto its own instance: - Its entries **exist nowhere else**, while its co-tenants hold replaceable copies. The worst cases are not comparable, so the shared posture cannot be right for both. - Its **latency requirement is tighter** than the worst operation any co-tenant is permitted to run. - Its **growth is unpredictable**, so it will repeatedly consume the shared ceiling as a surprise. - It needs a **different posture** - a different behaviour at the ceiling, a different persistence choice, a different upgrade cadence - and those are single-valued per instance. - Its **cleanups or bulk loads are routine**, which means the procedure will eventually be skipped by someone in a hurry. ## The contract to write down 1. **Who may share at all**, expressed by what the data is rather than by team: replaceable copies may share; state that exists nowhere else gets its own instance. 2. **What one tenant's mistake is allowed to cost**, stated as a number the co-tenants can plan against rather than as an aspiration. 3. **Who changes the instance's settings** - the ceiling, the ceiling posture, the persistence posture, the restart and upgrade schedule - and how the other occupants are told. 4. **Which signals page the platform and which page the owner**: instance-level health is the platform's, per-owner usage against quota is the owner's. 5. **What the exit looks like**, so a tenant that outgrows the shared tier is moved on a plan instead of after an incident. ## What varies, and what to verify A few stores in this class, and several managed offerings, do provide per-owner containers or quotas. Where one exists, establish exactly what it bounds before relying on it: some bound memory and request capacity, others only partition the namespace, which is accounting wearing an enforcement badge. Verify it the same way you would verify any other claim on this tier - by making a tenant exceed it in a test instance and watching whether the neighbour notices.