How would you design the backend check for a report quota?

What's really being asked

At a senior level, this question reveals whether you treat a quota as a consistency boundary rather than a simple conditional. Interviewers want to see if you consider race conditions, distributed state, and user experience when a hard business limit is hit. The goal is not to recite a pattern but to show you can prevent overages without destroying performance.

The full answer

A good answer hits four things in order. First, placement: enforce the check in the backend service or API gateway, never the client, because clients can be bypassed. Second, correctness under concurrency: use a database constraint like a partial unique index with a computed column, an atomic counter increment in Redis or SQL, or a pessimistic lock on a user row so two simultaneous requests cannot both slip through. Third, user experience: return a specific 403 Forbidden or 429 Too Many Requests with a message like Report limit reached rather than a generic 500, and consider surfacing current usage in the UI preemptively. Fourth, lifecycle edge cases: handle plan downgrades by grandfathering or pruning, account for async report generation that may pend for minutes, and decide whether soft limits with warnings or hard limits with rejection are appropriate for the product.

The mistakes people make

The classic red flag is describing a two-step read-then-write where you SELECT COUNT from a reports table and then INSERT if the count is below the threshold; under load this will over-report because the count can change between the query and the insert. Another red flag is relying on cached counts from a read replica or CDN without a freshness guarantee. Suggesting rate limiting as a substitute for a quota is also a miss because rate limits cap speed, not total inventory.

What usually comes next

An interviewer might ask how you would handle a user who creates ninety-nine reports and then triggers two simultaneous creation requests, or how you would enforce the quota if reports are created by an asynchronous worker rather than a synchronous API call. They might also ask how you would let an admin override a quota or how to support metered billing where overages are allowed but charged.

A concrete example

Suppose you store a reports_count column on the users table. When a creation request arrives, you open a transaction and issue UPDATE users SET reports_count = reports_count + 1 WHERE id = 123 AND reports_count < 100, then check the affected rows. If zero rows were updated, you reject with a 403. This is a single atomic operation that requires no explicit lock and works in standard SQL. For extra safety, you add a check constraint or a trigger that aborts inserts into the reports table when the owner has reached their plan limit.