A limit is a business rule with concurrency A SaaS plan may allow a number of users, stored files, API calls, or processed documents. A naive check of coun...
A limit is a business rule with concurrency
A SaaS plan may allow a number of users, stored files, API calls, or processed documents. A naive check of count() followed by create() can allow two simultaneous requests to exceed the limit. The system must define what is counted, when usage resets, and which action occurs at the boundary.
Separate an entitlement such as "up to ten team members" from metered usage such as "fifty thousand API calls this month." Store the plan's effective features as versioned configuration so an old subscription can be interpreted even after the catalog changes.
Define the measurement window
For monthly quotas, decide whether the period follows calendar months or the billing cycle. Record start and end timestamps in a consistent timezone. Specify whether failed requests count, whether retries consume quota, and whether an upgrade increases the current period's allowance.
Use a stable operation or request ID for billable events. If the same API call is retried, count it once when the business rule calls for one operation.
Enforce atomically
For a small counter in one database, lock the usage row inside a transaction before checking and incrementing. For high volume events, use an atomic store or append usage events and reconcile them against a durable ledger. A cached displayed count is useful for UI feedback but must not be the sole enforcement source.
Soft limits can warn users without rejecting work. Hard limits need a predictable API response and a clear upgrade or wait path. Avoid presenting a generic server error when a quota was reached.
Handle plan changes
When a customer downgrades below current usage, define whether existing data remains readable and whether new creation is blocked. Do not delete customer records just to make a number fit. Support staff need to see the entitlement, usage calculation, and next reset time.
Test race and recovery paths
Run concurrent creation requests just below the limit and verify the accepted count. Test duplicated events, period rollover, canceled subscriptions, and provider webhook delays. Audit a few real usage records against the displayed counter.
Conclusion
Usage limits are reliable when their definitions, atomic enforcement, and reconciliation are explicit. The web and SaaS development service covers metering within a broader subscription architecture.
References