Katkat
Back

Design A Drive-Style Usage Quota Limiter

GoogleSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a distributed storage quota accounting and enforcement service for a cloud drive platform that handles concurrent multi-part uploads, deletions, retries, and usage drift reconciliation.

Scenario

In personal and enterprise cloud storage platforms (e.g., Google Drive, Google Workspace), users have finite storage limits (e.g., 15 GB free tier, pooled team drives). Files can be uploaded via chunked multi-part sessions that take minutes or hours, and multiple uploads or deletions may occur concurrently.

Design a Usage Quota Limiter and Accounting Service that accurately tracks byte consumption and prevents users from exceeding their allocated storage limit during uploads, modifications, and deletions.

Requirements

Functional Requirements

  • Reserve Quota: When a client initiates an upload with a declared byte size, reserve that capacity so concurrent operations do not exceed the user's quota.
  • Commit & Release: Commit reserved bytes upon upload finalization. Release uncommitted reservations on upload cancellation, client drop-off, or TTL expiration.
  • Reclaim Quota: Instantly or near-instantly reflect space freed by deletions or moving items to trash (based on policy).
  • Reconciliation: Provide an asynchronous background mechanism to correct drift between quota records and actual object storage usage (e.g., caused by network partitions, out-of-order events, or aborted multipart uploads).

Non-Functional Requirements

  • Latency: Reservation check must complete in < 25 ms (p99) to keep upload initiation snappy.
  • Scale: 1 billion total user accounts; 100 million daily active users; 50,000 upload initiations per second at peak.
  • Consistency: Hard quota guarantees should prevent severe oversubscription (small bounded overages during bursts are acceptable if justified by latency trade-offs).
  • High Availability: 99.99% uptime for quota verification so file access is not blocked.

Key Areas to Cover

  1. APIs: Endpoints for quota check/reservation, commit, release, and querying usage.
  2. Reservation Lifecycle: State machine for handling multi-part uploads, timeouts, retries (idempotency), and size mismatches (actual file size differs from estimated size).
  3. Data Model & Storage: Database schema for tracking current usage, pending reservations, and tier limits, including caching strategies.
  4. Concurrency & Race Conditions: Handling multiple concurrent uploads when a user is near their quota ceiling.
  5. Reconciliation Pipeline: Architecture for detecting and fixing discrepancies between blob storage metadata and user quota balances.

Hints

Hint 1

Treat the upload flow as a two-phase operation: a temporary quota lease with an expiration TTL, followed by a final commit or release.

Hint 2

To handle high-throughput concurrent uploads near quota boundaries, partition or shard user quota counters and consider using atomic conditional writes (e.g., Redis Lua scripts or database compare-and-swap).

Hint 3

Design the reconciliation worker to process immutable storage change-data-capture (CDC) logs or periodic snapshot diffs rather than scanning active database rows.

Follow-up questions

  • How would your design change if storage quotas are shared across a team/domain with thousands of concurrent members?
  • How do you handle 'sparse' files or server-side deduplication/compression where the disk footprint does not match the logical file size?
  • If the quota database becomes temporarily unreachable, what is your fallback strategy: fail open (allow upload) or fail closed (block upload)?