How would you design hierarchical storage quotas per tenant/user?

Hierarchical storage quotas are essential for multi-tenant platforms where multiple users or sub-accounts share common resources. They ensure that no user or project exceeds their allocated space while maintaining fairness and scalability.

Introduction

Hierarchical storage quotas allow platforms to enforce storage limits at multiple levels like organization, project, and user. Each child node in the hierarchy cannot exceed its quota, and collectively, children cannot exceed the parent’s quota. It’s like managing budgets across departments. if a department’s total spending exceeds the company limit, everyone feels the impact.

Why It Matters

In scalable systems, especially multi-tenant architectures, uncontrolled usage by one tenant can affect others. Hierarchical quotas prevent resource exhaustion, ensure predictable billing, and enforce fair usage. In interviews, this problem tests your understanding of distributed counters, consistency, and concurrency.

How It Works (Step-by-Step)

1. Model the hierarchy Create a tree where each node (organization, project, user) contains metadata such as limit_bytes, used_bytes, and parent_id.

2. Introduce a metadata service All write operations go through a quota service that verifies whether an operation fits within the quota before committing to storage.

3. Fetch ancestor chain When a user uploads or writes data, fetch all ancestors (user → project → organization) and check remaining space at each level. Cache this chain for performance.

4. Calculate headroom Compute available headroom for every ancestor as limit - used. Approve the write only if all nodes have enough space.

5. Create reservations Before writing, reserve space atomically across all ancestors using compare-and-set or transactional updates. These temporary holds prevent race conditions.

6. Commit after success Once data is written successfully, finalize the reservation and increment usage counters. Roll back reservations for failed or canceled writes.

7. Reconciliation Run background jobs that periodically verify counters against actual storage. Fix discrepancies caused by failed operations or deletions.

8. Handle deletes and moves On deletes, subtract usage up the hierarchy. For file moves, perform a decrement on the source path and increment on the target path, both validated through the quota chain.

9. Alerting and monitoring Send events when usage nears thresholds (e.g., 80%, 95%). Allow tenants to view or request quota increases.

10. Multi-region scaling Maintain regional counters for speed, and aggregate periodically for global enforcement.

Real-World Example

Consider a photo storage service like Google Drive. Each organization gets 1TB, each project 100GB, and each user 10GB. When a user uploads a file, the system checks available quota for the user, their project, and their organization. If the upload would cause any ancestor’s limit to be exceeded, the operation fails gracefully, alerting the user.

Common Pitfalls or Trade-offs

Race conditions: concurrent uploads without atomic reservations can overcount or undercount.
Counter drift: deletions or retries may desync counters; reconciliation jobs are vital.
Lock contention: high-traffic tenants can cause database contention; sharded counters help.
Global consistency: enforcing global hard caps across regions increases latency.
Depth of hierarchy: very deep trees slow checks; cache parent chains efficiently.

Interview Tip

Interviewers often expect you to describe how you enforce limits atomically and how you maintain accuracy. Start by describing your quota model, explain reservation-based updates, and close with how you handle retries and reconciliation. This shows strong system design reasoning.

Key Takeaways

Maintain quotas at every level of the hierarchy
Use atomic reservations to prevent overuse
Periodically reconcile counters with storage
Add alerts and soft limits for smooth user experience
Scale via sharded or regional counters

Table of Comparison

Approach	What It Controls	Best For	Complexity	Notes
Hierarchical quotas	Bytes and object counts across multi-level tenants	SaaS or storage systems	High	Fair and flexible but requires careful design
Flat per-user quotas	Limits only at the leaf node	Small apps or single-level systems	Low	Simple but lacks aggregation control
Tag-based budgets	Limits grouped by tags or teams	Cross-functional resource tracking	Medium	Great for flexible billing models
Rate limiting	Controls request rate or bandwidth, not storage size	APIs or bandwidth enforcement	Low	Complements quota systems

FAQs

Q1. What is a hierarchical storage quota?

It’s a system that enforces storage limits across multiple hierarchy levels, such as organization → project → user, ensuring no level exceeds its quota.

Q2. How are hierarchical quotas different from flat quotas?

Flat quotas only enforce limits per user or project, while hierarchical quotas cascade limits across multiple levels.

Q3. How can I ensure accurate quota tracking under concurrency?

Use reservation-based updates with idempotent request IDs to prevent double-counting or missing updates.

Q4. What if usage counters drift from actual data?

Run periodic reconciliation jobs that compare logical counters with real storage metrics and correct mismatches.

Q5. Should I track logical or physical bytes?

Logical bytes are preferred for product-level visibility and billing, while physical bytes suit infrastructure cost tracking.

Q6. How do I scale quota enforcement globally?

Use local quota checks for speed and a global aggregator for final enforcement. Introduce conservative buffers for consistency.

Further Learning

For a step-by-step understanding of quota enforcement, counters, and background reconciliation, start with Grokking System Design Fundamentals.

If you want real-world design case studies that include quota systems, counters, and distributed coordination, explore Grokking Scalable Systems for Interviews.

To practice interview-style system design questions with scoring and feedback, enroll in Grokking the System Design Interview.