Lumen Rate Limiting Laravel Package

Product Decisions This Supports

• API abuse & cost control: Rate limiting is a security/reliability control (credential stuffing, scraping, runaway clients, third-party integration misbehavior). Shipping it is a risk-reduction decision, not a feature decision.
• Tiered plan enforcement: Per-key/per-route limits are the mechanism behind "Free / Pro / Enterprise" quotas. This package gives us that primitive on Lumen without building a bespoke middleware.
• Build vs. buy (build vs. adopt): The alternative is ~100 lines of in-house middleware plus tests and ongoing ownership. Adopting a small, focused package is cheaper if we accept the maintenance-risk trade-off (see below).
• Roadmap dependency, not a roadmap item: v2.0.0 exists to track Lumen 11. Its real product value is that it unblocks our Lumen 11 / PHP 8.2+ upgrade, which is where the security-patch and support-window value sits.
• Platform boundary decision: If we are on full Laravel, this package is largely redundant (framework throttle middleware + RateLimiter facade). Adopting it is implicitly a statement that we are staying on Lumen for this service — worth confirming rather than drifting into.

When to Consider This Package

Consider it when:

• The service runs on Lumen, not full Laravel, and needs request throttling. Lumen omits much of the framework's routing/middleware conveniences, so this fills a real gap rather than duplicating one.
• You are already committed to Lumen 11 — v2.0.0's only change is Lumen 11 support, so it is only useful after the platform upgrade.
• Your limiting needs are simple and local (per-IP, per-API-key, fixed/sliding window via the cache store). Low-to-moderate traffic, single-region.
• You want a small, auditable surface: a thin middleware is easier to review and fork than a broad "API management" dependency.

Look elsewhere when:

• You are on full Laravel — use the built-in throttle middleware and RateLimiter; adding a third-party package here is pure dependency debt.
• You need edge/gateway-level protection (WAF, CDN, API gateway quotas). Application middleware is the wrong layer for volumetric DoS and should not be pitched as such.
• You need globally consistent limits across many services/regions — validate the cache backend (Redis) and clock/atomicity behavior before committing; this package does not solve distributed coordination for you.
• Maintenance risk is unacceptable: this is a single-maintainer package, v2.0.0's sole change is a compatibility bump, and there is no visible security-response process. If rate limiting is a compliance control with an audit trail, you need either a vendor with an SLA or an in-house implementation you own.
• Treat v2.0.0 as breaking. The major bump from 1.2.0 almost certainly narrows the illuminate/* / PHP constraints and drops Lumen 8–10 support. Verify no other dependency in the service pins an older Lumen, and confirm the upgrade order: platform first, then this package.

Adoption checklist for the PM: confirm Lumen 11 target date, confirm cache store (Redis vs. array) for limit accuracy, pin the version explicitly, and name an owner plus a fallback plan (fork/vendor the middleware) in case upstream goes quiet.

How to Pitch It (Stakeholders)

To executives (one line): We are adopting a small, free middleware to close a real API abuse/over-quota gap on our Lumen service; it costs us almost nothing and rides along with the Lumen 11 upgrade we already need to do.

To executives (the honest caveats): It is maintained by a single individual, so it is a convenience, not a guarantee. Mitigations: we pin the version, we keep the fallback of owning ~100 lines of middleware, and we do not count it as our defense against a serious denial-of-service attack — that stays with our CDN/gateway. Rate limiting here is about fairness, cost control, and abuse friction, not about absorbing a targeted attack.

To engineering: v2.0.0 is a compatibility release, not a feature release — Lumen 11 support only, and the major version signals dropped support for older Lumen. Sequence it after the Lumen 11/PHP 8.2 upgrade; review the 1.2.0→2.0.0 diff (it should be constraint changes, not logic), pin the version in composer.json, and add a test that asserts the limit is actually enforced on a representative route. Confirm behavior against our production cache store, not the array driver — the local driver gives per-process limits that look correct in tests and fail in production.

To security/compliance: treat this as a contributing control, not a primary one. It gives us per-client throttling and a signal for abuse detection, but it has no audit trail, no vendor SLA, and no published security-response process. Log limit breaches so we get detection value out of it rather than silent 429s.