Kaveh Laravel Package

Product Decisions This Supports

• Production-readiness gate for telemetry/event shipping: v0.2.5 is the first release with meaningful failure handling — a circuit breaker (3 consecutive failures → 60s cooldown) and hard timeouts (1.0s connect, 3.0s request). This is the release that makes the package defensible in a customer-facing request path rather than only in async jobs.
• Build vs. buy for the delivery layer: The resilience features shipping here (breaker, timeouts, non-blocking fallback) are exactly the custom code most teams write when they hand-roll a remote event/transport client. Adopting shifts effort from "how do we not hang a worker" to "what do we send and why."
• Roadmap: Octane and long-running-runtime support. The explicit EventBuffer non-blocking fallback for Octane signals the maintainer is targeting modern Laravel deployments. If Octane/RoadRunner/FrankenPHP is on your 2–3 quarter roadmap, this removes a known blocker.
• Incident-blast-radius decisions: Timeouts cap worst-case added latency per request at ~3s (connect + request), and the breaker caps sustained exposure at one 60s window per 3 failures. This is the input you need to decide whether the package can sit inline versus behind a queue.
• Use cases unlocked: product analytics/event capture, audit trails, feature-flag or experiment exposure logging, and third-party usage metering — anywhere a durable local buffer plus best-effort remote delivery is acceptable.

When to Consider This Package

Consider it when:

• You are on Laravel 10/11 and want event/telemetry delivery that already handles worker-hang protection and transient downstream outages without bespoke retry code.
• You run Octane or another long-running worker — this release explicitly addresses non-blocking behavior in EventBuffer, which is where most naive buffers corrupt state or stall the event loop.
• Your downstream endpoint is best-effort, not transactional. The breaker trades delivery for availability: events buffered during a 60s cooldown are dropped or delayed depending on buffer policy — confirm which before committing.
• You want a small, auditable dependency rather than a full analytics SDK; the removal of a bogus illuminate/foundation requirement also suggests the maintainer is actively trimming install friction.

Look elsewhere when:

• You need guaranteed, at-least-once delivery with durable persistence and replay. A 60s circuit breaker plus in-memory EventBuffer implies loss on trip and on process exit.
• You need stable public API guarantees. At 0.2.x this is pre-1.0; pin the exact version and expect breaking changes before 1.0.
• Your workload is high-volume batch where a hard 3.0s per-request timeout and 3-failure trip threshold will shed load you actually wanted to keep — you would need per-environment tuning that may not be configurable yet.
• You require vendor SLA/support — a single-maintainer pre-1.0 package is a dependency-governance conversation, not just a technical one.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that handles a problem every product with telemetry eventually pays for — what happens when the analytics/logging endpoint goes down. The new release adds automatic fail-fast (stops calling a broken endpoint for 60 seconds after 3 failures) and hard timeouts so a slow third party can never stall our application. Net effect: we avoid building and maintaining that resilience logic ourselves, and we remove a concrete risk of user-facing slowdowns caused by a downstream outage. Risk to flag: the package is pre-1.0 (v0.2.5), so we pin the version and treat upgrades as reviewed changes, not automatic.

To engineering: v0.2.5 makes this safe to run in the request path or in Octane workers. Specifically: RemoteTransport now trips a circuit breaker after 3 consecutive failures with a 60s cooldown; connect and request timeouts are capped at 1.0s and 3.0s so a hung endpoint cannot exhaust PHP-FPM workers; and EventBuffer has an Octane-safe non-blocking fallback. A bogus illuminate/foundation composer requirement was also dropped, cleaning up install/conflict behavior. Two things to verify before adoption: (1) what the buffer does with events accumulated during a breaker cooldown — drop or retain; (2) whether breaker threshold, cooldown, and timeouts are configurable per environment, since a 3-second ceiling is generous for inline use and stingy for batch backfills. Recommendation: adopt behind a feature flag in one non-critical event stream first, instrument breaker-trip counts as a metric, and revisit at 1.0.