Kv Laravel Package

Product Decisions This Supports

• Runtime/infrastructure standardization: Whether to standardize key-value access for PHP services already running on RoadRunner, using the official SDK instead of hand-rolled RPC clients or direct Redis coupling.
• Build vs. buy: Use roadrunner/kv when the RoadRunner KV plugin is already part of the platform; avoid building a custom KV client. Do not adopt it as a replacement for Laravel’s cache/session abstractions without a clear RoadRunner-specific need.
• Feature enablement: Short-lived cache entries, counters, idempotency keys, feature-flag snapshots, worker-shared ephemeral state, and other simple KV use cases—provided TTL, consistency, and driver behavior are validated.
• Roadmap gating: Fund integration only if RoadRunner adoption is strategic. Otherwise, defer and keep using Laravel cache/Redis to avoid adding an immature dependency.
• Architecture risk management: Put the SDK behind an internal interface so the product can fall back to Laravel cache, Redis, or another KV backend without rewriting feature code.

When to Consider This Package

Consider it when:

• The service already runs on RoadRunner and uses the RoadRunner KV plugin.
• You need a PHP SDK for simple get/set/delete-style KV operations from workers.
• You want to avoid maintaining a custom RoadRunner RPC client.
• You can tolerate low community adoption: 11 stars, 0 dependents, and limited public production evidence.
• You will pin versions, verify release provenance, test driver behavior, and wrap the SDK behind an internal abstraction.

Look elsewhere when:

• The application is Laravel-first and already fits Laravel cache, sessions, queues, and Redis cleanly.
• You need advanced Redis features such as pub/sub, streams, Lua scripting, complex data structures, or mature managed-cache operations.
• You require strong ecosystem support, broad production adoption, or predictable long-term community maintenance.
• You need strict durability, multi-tenant access control, rich observability, or vendor-supported SLAs.
• Adopting RoadRunner itself is not already justified.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost integration for services already committed to RoadRunner. It can reduce bespoke infrastructure code and simplify access to RoadRunner’s KV layer, but its low adoption means it should be treated as a pilot or tactical dependency—not a platform bet.

For engineering: roadrunner/kv is the official-style PHP SDK for RoadRunner KV storage. It reduces custom RPC work and helps isolate KV usage from a specific backend. However, with 11 stars and 0 dependents, we should pin the version, verify compatibility and release history, test failure modes, and keep a fallback to Laravel cache/Redis behind an internal interface.

For product: It enables fast ephemeral-state and caching use cases only if RoadRunner is already part of the stack. It is not a reason to change runtimes, and it should not be used for critical data without proven operational guarantees.