Laravel Fixed Window Limiter Laravel Package

Product Decisions This Supports

• Choosing rate-limit semantics — the decision that actually matters. This package forces an explicit product choice: fixed-window counters ("100 requests per minute, resets at :00") versus sliding-window or token-bucket behavior. Fixed windows are cheap, trivially explainable to customers, and easy to surface in UI ("resets in 42s"). The tradeoff is the well-known boundary burst — traffic can momentarily reach ~2x the configured limit across a window edge. For some surfaces that is fine; for fairness-sensitive or billing-adjacent quotas it is not. The package is valuable here mainly as a concrete model of that tradeoff, not as a dependency.
• Mirroring external partner quotas. Fixed windows map cleanly onto how many third-party APIs advertise X-RateLimit-Remaining and reset times. If the product's job is to stop our outbound calls before a partner returns 429s — and to show customers a "calls remaining / resets at :00" panel that matches the partner's mental model — fixed windows are the right semantics. This package is a useful reference implementation for that requirement, not necessarily the production dependency.
• Build vs. buy vs. fork vs. skip. With 67 stars, zero dependents, an archived repo, and a January 2020 last release, cost is not the question. The question is whether to carry an unmaintained dependency in a reliability-adjacent area. PM framing: use framework primitives, reimplement in ~30–50 lines over Redis INCR + PEXPIRE, fork with a named owner, or skip entirely. Those are the four real options; the package is one column in the table.
• MVP scoping and risk tiering. Supports shipping coarse limits now on low-risk surfaces — login/OTP attempt caps, webhook throttling, expensive export/report endpoints, internal admin actions, outbound third-party protection — while deferring per-tenant quota systems, billing-linked limits, and public API contracts to a properly owned implementation.
• API contract and UX decisions. The limiter's shape drives customer-visible behavior: the 429 response body, Retry-After vs. reset-timestamp headers, error copy, and whether the countdown a user sees is honest. Fixed windows make "resets at :00" truthful; decay-based throttling does not. That is a product-facing decision worth making deliberately.
• Dependency governance and roadmap. Establishes whether rate limiting sits on the critical path, and sets precedent: do we accept archived dependencies at all, and under what exception process? Anything customer-facing with an SLA, contractual quota, or security-sensitive enforcement should not be built on an archived package.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining a legacy Laravel application (Laravel 6/7-era) already running Redis and a compatible PHP version, so installing is low-friction rather than a Composer constraint fight.
• The limit is non-critical: internal endpoints, background-work throttling, or mirroring a third-party quota — not revenue commitments, public API contracts, or security-sensitive flows.
• Fixed-window behavior is explicitly acceptable, including the documented property that traffic can burst up to ~2x the configured limit across a window boundary.
• The team accepts ownership of a fork or vendored copy — tests, security review, a compatibility matrix (PHP 8.1–8.3, Laravel 10–12, Redis 6/7, both predis and phpredis), and an eventual removal plan.
• You need a reference implementation or a short-term bridge, not a strategic dependency.
• A specific engineer is named as owner. If no one will own it, do not adopt it.

Look elsewhere when:

• You are starting a new Laravel service or targeting modern Laravel — native Illuminate\Cache\RateLimiter plus throttle: middleware already delivers fixed-window limiting on any cache store, including Redis, with a supported upgrade path.
• You need maintained support, security patching, or modern Redis compatibility guarantees.
• You need sliding-window, token-bucket, or leaky-bucket behavior for fair customer quotas. If sliding-window semantics are acceptable, the case for this package collapses entirely.
• You need multiple cache stores, per-tenant hierarchies, audit trails, dashboards, or billing-grade observability.
• The limit protects login, payments, or partner-facing SLAs.
• You cannot fund the recurring maintenance line item — dependency bumps at every Laravel major, manual Redis-client upgrade testing, and no upstream to lean on.

How to Pitch It (Stakeholders)

Executive summary. This package solves a narrow, well-understood problem — fixed-window rate limiting for Laravel and Redis — with predictable reset times and a familiar API. It is also archived, last released January 2020, with 67 stars and zero dependents, and carries no support or security-response path. Recommendation: do not add it to critical paths for new work. If fixed-window limits are genuinely required, use framework primitives or fund a small internal utility (~30–50 lines over Redis INCR + PEXPIRE) with a named owner and tests. If it already exists in the codebase, contain it: document the owner, pin the version, and schedule replacement. Either way this is a governance decision — whether we accept an unmaintained dependency in a reliability-adjacent area — not a build-cost one.

Engineering summary. Mechanically it is a small MIT-licensed limiter over Redis cache, and effectively a redundant abstraction: Laravel's first-party RateLimiter already implements fixed windows on any store. Its 2020 constraints will likely require --ignore-platform-reqs, a Composer alias, or a fork to run on Laravel 10–12 — any of which converts an install into owned code. If adopted: vendor and pin it; verify atomicity of the increment-and-expiry path (a non-atomic INCR + EXPIRE can permanently throttle an identity if the process dies between calls); confirm fail-open vs. fail-closed behavior under Redis outage; add boundary-burst tests; validate against PHP 8.1–8.3 / Laravel 10–12 / Redis 6–7 with both clients; and canary one low-risk endpoint behind a feature flag. Prefer RateLimiter or a tested in-house Lua-backed limiter unless this package is already embedded in a legacy path — in which case treat the work as a migration with a documented rationale, not an adoption.