Per-Tenant Quotas

Imagine an apartment building where every unit has its own water meter and its own monthly cap. If one tenant runs the tap all day, it only counts against their own meter. It doesn't use up water that belongs to the tenant next door, and it doesn't get shut off because someone else went over. A 'tenant' in cloud software means the same thing as in the building: one customer, or one company's account, using a shared system. A 'quota' is that customer's personal cap: a fixed amount of some resource, such as storage, API calls, or uploaded video minutes, that they can use before the system says no more, at least until the cap resets.

1. 1Give every tenant their own running usage counter, starting at zero, and their own quota: the cap they're allowed to reach.
2. 2When a tenant makes a request that consumes some amount of the resource, check: would adding this amount push them over their quota?
3. 3If there's room, allow it and add the amount to that tenant's counter. Only that tenant's counter changes.
4. 4If it would go over, deny the request and leave their counter untouched. One tenant hammering the system can't eat into anyone else's allowance.

Use this for any system serving multiple customers off shared infrastructure — a SaaS product, a multi-tenant API, cloud storage sold by the gigabyte. Per-tenant quotas keep one customer's traffic spike or runaway script from starving everyone else. They're also how usage-based billing tiers get enforced.

• ⚠Tracking one shared counter for everyone instead of one per tenant. That turns a single noisy customer into an outage for every other customer sharing the pool.
• ⚠Letting a request partially succeed when it would go over quota, using up whatever room is left, instead of cleanly allowing it in full or denying it in full. Partial writes get confusing fast.
• ⚠Forgetting to handle a tenant that doesn't exist in the system at all. That should be denied outright, not silently treated as having unlimited quota.