Design a Shared User Quota Service That Never Overdraws

Design a quota service. Each user has one quota that several of the company's services draw from: before doing work for a user, a service asks the quota service to consume part of that user's quota. The balance must never be overdrawn, even when many services consume from the same user at the same moment, and the quota must be strongly consistent under high concurrency. ```hint Check and consume as one step Consider what goes wrong when a service reads the remaining balance and then, in a separate step, writes the new one, and what storage operation removes that gap. ``` ```hint One hot user Think about what limits throughput when every request for one heavy user lands on the same record, and how that user's quota could be divided without risking an overdraft. ``` ### Constraints and Clarifications - Given: several services share one quota per user, overdrafts are never allowed, and consistency must hold under high concurrency. - Not given: what the quota measures, whether it resets, the number of users, the request rate, or the latency a check may add. Ask, or state your assumptions. ### Clarifying Questions - What does the quota measure: API calls, compute credits, storage bytes? Does it reset each period? - Do services know the cost of an operation before they start it, or only after it finishes? - If an operation fails after its quota was consumed, should the quota be returned? - How much latency may a quota check add to a request, and from how many regions do services call? - What should a service do when the quota service cannot be reached? - Can an administrator change a user's limit in the middle of a period? ### What a Strong Answer Covers - Settles the unit, reset policy, cost knowledge, refunds, latency budget and failure behavior first - An API that supports retries safely, such as reserve, commit and release with idempotency keys - An atomic conditional update that makes overdrafts impossible, and why read-then-write fails - Partitioning by user, replication that does not lose consumption on failover, and a plan for hot users - Reservations that expire, periodic resets without a reset storm, and an audit ledger - The trade-off between strong consistency and latency or availability, stated explicitly ### Follow-up Questions - One enterprise user sends tens of thousands of requests per second. How do you keep that user's quota from becoming a bottleneck? - Services run in three regions. Where does the quota live, and what does a check cost from the far regions? - A service consumes quota and then crashes before finishing the work. What happens to that quota? - Billing needs an exact usage record per user per month. How do you reconcile it with the live counters?