Rate Limiting Laravel Package

Product Decisions This Supports

• Launch gating for public APIs. Deciding whether the next milestone can ship an externally-consumable API depends on having per-key, per-tenant throttling with observable 429s. A rate limiter is a prerequisite for that roadmap item, not a nice-to-have.
• Build vs. buy vs. borrow. This package is a borrow candidate: it lets you answer "do we build our own limiter?" with "no, not yet" — but only after diligence, because zero stars and zero dependents mean you are effectively adopting an unvalidated source tree rather than a maintained product.
• Monetization and fair-use tiers. If the roadmap includes usage-based plans, per-plan quotas, or "burst then sustained" limits, the algorithm choice (fixed window vs. sliding window vs. token bucket) becomes a pricing decision, not just an engineering one. A package that exposes multiple algorithms keeps that product decision reversible.
• Abuse and cost containment. Login/OTP brute-force protection, webhook ingestion floods, and expensive downstream calls (LLM tokens, SMS, third-party API spend) are all product-level risk decisions that a limiter operationalizes.
• Non-HTTP paths. Requests handled outside Laravel's middleware lifecycle — queue jobs, scheduled commands, websocket messages, service-layer calls to a vendor — are where a framework-agnostic PHP limiter creates decision space that Laravel's built-in middleware does not.
• SLO and reliability tradeoffs. Choosing to shed load (429) versus queue versus degrade is a product-visible behavior. Having a limiter you can tune without a deploy is what makes that a decision rather than an incident.

When to Consider This Package

Consider it when:

• You need limiting outside the HTTP request lifecycle (jobs, CLI, workers, cross-service calls) and want one consistent policy across those surfaces.
• You need an algorithm Laravel's built-in limiter doesn't give you cleanly: token bucket with burst, sliding-window log/counter, or concurrency/semaphore limiting rather than requests-per-minute.
• You want a pluggable store abstraction (Redis, Memcached, DB, in-memory) so the backend is an infrastructure choice, not a rewrite.
• You're comfortable treating it as a vendored reference implementation: fork it, own it, pin it, and accept that "0 dependents" means no upstream bug-finding community. Apache-2.0 makes that legally clean.
• You're doing a time-boxed spike to evaluate algorithms before committing to an in-house implementation.

Look elsewhere when:

• The default case applies. Laravel ships RateLimiter, Limit::perMinute()/perHour()/perDay(), and the throttle middleware, plus named limiters and per-user keys. For standard HTTP endpoints this is already solved — adopting a third-party package here adds supply-chain risk for zero capability gain.
• You need proven operational maturity. At 0 stars / 0 dependents, there is no evidence of production use, no CVE history, no maintainer bus factor. For anything in the critical path, prefer Symfony's RateLimiter component or a mature token-bucket library.
• You need edge/global limiting. Cloudflare, an API gateway (Kong/Envoy/AWS API Gateway), or Redis-with-Lua at the ingress layer will outperform and out-survive any in-app PHP limiter for volumetric protection.
• You need multi-region or exactly-once accounting. In-process PHP limiting degrades to per-node limiting unless the store is shared and atomic; be explicit that this package inherits whatever guarantees your backend provides.
• It isn't actually Laravel-integrated. The description says "PHP rate-limiting," not a Laravel package — verify there's a service provider, facade, config publish, and middleware. If not, budget integration work in the comparison.

How to Pitch It (Stakeholders)

To executives (one paragraph): Rate limiting is a launch prerequisite for our public API and a direct control on variable cost. Laravel already includes a capable built-in limiter that covers our standard HTTP endpoints at zero added dependency risk, so this package is not a default adoption. It is worth a short evaluation because it offers algorithms and non-HTTP coverage the framework doesn't, and its permissive Apache-2.0 license means we can vendor it if we choose. Recommendation: do not add it as a dependency of record; run a two-week spike behind an internal interface so we keep the option without taking the risk.

To engineering:

• Wrap any third-party limiter behind our own RateLimiter interface from day one. That makes the choice reversible and contains the blast radius of an abandoned upstream.
• Explicitly document the store and its atomicity guarantees — the limiter is only as correct as the backend.
• Treat the "0 stars, 0 dependents" signal as a real risk: assume no upstream support, pin the version, vendor the source, and assign an owner for the fork.
• Verify the release/provenance metadata before the spike; a single release with no adoption footprint should be read as "unmaintained until proven otherwise."

To product/design:

• Decide the user-facing contract up front: what a 429 looks like, whether Retry-After is surfaced, and whether limits are visible in the UI. The package choice doesn't decide this — you do, and it's cheaper to decide before implementation.