Laravel Quota Laravel Package

Product Decisions This Supports

• Monetization and packaging design. The package makes usage-based tiers a first-class concept rather than a bespoke feature: Quota::for('monthly_exports', $user)->limit(50)->perMonth() is a one-line expression of a pricing plan limit. PMs can prototype and iterate on tier boundaries (Free/Pro/Team) without asking engineering for a new subsystem each time the pricing page changes.
• Build vs. buy (adopt) decisions. A calendar-period quota system with atomic consumption, middleware enforcement, persistence, and pruning is roughly 2–4 weeks of engineering plus ongoing maintenance. This is an MIT-licensed, drop-in substitute for that work — a straightforward cost-avoidance decision for most Laravel teams.
• Freemium and trial gating. Daily/monthly caps on exports, AI prompts, API calls, and workspace creation are the standard levers for converting free users. The expressive API lowers the cost of testing which limit actually drives conversion.
• Fairness and support policy. The middleware only consumes quota on 2xx/3xx responses — failed validation (422) or server errors (500) don't burn a user's allowance. That's a defensible, user-friendly policy we can state publicly, and it removes a common support-ticket category. Similarly, reset()/set()/decrement() give support agents a sanctioned remedy for "I got charged for a broken request."
• Abuse mitigation vs. availability. Crucially this does not replace Laravel's RateLimiter. The decision it supports is the two-layer split: RateLimiter for burst/DDoS protection at the edge, this package for cumulative budget policy at the application layer. Teams that conflate the two ship either brittle throttles or unenforceable quotas.
• Storage tradeoff as a product decision. cache driver for high-frequency, low-stakes counters (per-minute API limits); database driver for anything a customer can dispute or that must survive a deploy/restart (billing-tier budgets). Being able to choose per-action (->using('database')) means PMs don't have to pick one policy for all limits.
• Roadmap sequencing for metering. This is a quota enforcer, not a usage ledger. It answers "can they do this?" not "what do we invoice them for?" Treat it as the fast path to shipping limits now, with a metering pipeline (Stripe metering, Lago, OpenMeter, or an in-house events table) as a separate, later initiative. QuotaConsumed/QuotaExceeded/QuotaReset events provide the hook to start feeding that pipeline cheaply.
• Observability requirements. The events are the seed of a quota-health dashboard: how often are users hitting walls, and on which limits? That's a direct input into whether a limit is too tight (churn risk) or too loose (margin risk).

When to Consider This Package

Adopt when:

• You're on Laravel 11/12+ and PHP 8.2+, the stack this is explicitly built and tested against.
• Your limits are calendar-aligned budgets — "50 exports per month," "1,000 API calls per day," "AI credits per billing cycle." This is exactly the gap the package fills, and it handles period rollover with no cron jobs.
• You need limits attached to entities beyond the current user — teams, tenants, API keys, workspaces — via the HasQuotas trait and polymorphic scoping.
• You want to ship in days. Installation is Composer + publish + migrate; route protection is a single middleware string (quota:exports,50,month).
• You're comfortable wrapping it: put it behind your own service class and use its QuotaDriverContract / Quota::extend() seam so a future replacement is a one-file change.

Look elsewhere or proceed with caution when:

• Adoption risk is your dominant concern. 110 stars and zero dependents means an unproven package with effectively no third-party battle-testing and an implicit single-maintainer bus factor. There is no SLA, no commercial support, no security response commitment. For a revenue-critical enforcement path in an enterprise context, budget for the possibility of forking (MIT makes this viable) or absorbing maintenance.
• You need invoice-grade accuracy. Quota counters are not a billing system of record. If finance, audits, or disputes require line-item usage history, reconciliation, or exactly-once attribution, you need a real metering/ledger product — this gives you counters, not a journal.
• Your services aren't all Laravel. The database driver helps across services sharing a relational DB, but there's no language-agnostic API or sidecar. Polyglot or multi-region architectures with strong consistency needs should build or buy a dedicated quota service.
• You need distributed-systems guarantees. The block() lock is scoped to the underlying cache store, not a globally consistent distributed lock. Very high concurrency on a single hot key should be load-tested before you trust it.
• Requirements are exotic — sliding windows, token-bucket burst allowances, per-request cost curves. Calendar periods are the design center; forcing it into a different shape will fight the abstraction.

How to Pitch It (Stakeholders)

To executives: We need per-user usage limits to sell tiered plans and control AI/compute costs. The build estimate is 2–4 weeks of senior engineering plus permanent maintenance. This package is MIT-licensed, covers the same ground (calendar budgets, persistent storage, automatic expiry, route-level enforcement, audit events), and gets us to a testable limit policy in roughly a day. The realistic risk is maturity: it's a low-adoption package with no commercial backing. We de-risk that by (a) isolating it behind our own thin wrapper and (b) budgeting a fallback fork, which the permissive license allows. Net: we trade a small maintenance bet for 3+ weeks of roadmap.

To engineering: It composes with RateLimiter rather than replacing it — keep the throttle for burst protection, use this for cumulative budgets. It fits your existing idioms: a fluent facade, an Eloquent trait, a middleware alias, config-published drivers, events on Laravel's dispatcher, and model:prune for cleanup. The parts that would be tedious and bug-prone to write — atomic consume-under-lock (block()), success-only middleware deduction, immutable period DTOs, per-action driver selection — are done. You own the integration surface and the driver, not the quota arithmetic. It also ships a Laravel Boost skill, so AI-assisted codegen will follow the package's conventions instead of inventing its own.

Guardrails to agree before adoption: decide per action whether it's cache (fast, lossy on restart) or database (durable, queryable); define the public message for exhausted quotas; wire the three events into monitoring before launch; and keep the package behind our own abstraction so a swap is cheap.