Laravel Hypercacheio Laravel Package

Product Decisions This Supports

• Queue infrastructure build-vs-buy: Informs whether to adopt a self-hosted, SQLite-backed queue with active-active replication instead of managed services (SQS, Redis Cluster) or a custom queue layer. This release strengthens the "buy/adopt" side by closing a durability gap that would otherwise force a bespoke fix.
• HA topology and SLA commitments: The OpQDel / OpQClear / OpQPush fixes mean queue state is now consistent across peer nodes. That directly supports decisions about whether the platform can promise multi-node failover for background processing without a shared external broker.
• Observability and metrics trustworthiness: Ghost "ready" jobs previously inflated backlog metrics in tools like Vigilance. Any roadmap item or alerting policy that depends on queue depth (autoscaling rules, on-call thresholds, capacity dashboards) can now be treated as reliable — a prerequisite for shipping customer-facing SLOs.
• Multi-tenant and multi-region roadmap: Cross-node queue clear (ClearQueueJobs) makes tenant-level "purge my queue" and environment reset workflows feasible in a clustered deployment, unlocking roadmap items previously scoped as manual ops work.
• Operational cost model: Reinforces the case for keeping queue state in-process/SQLite (low infra footprint) versus adding a managed broker line item — relevant to pricing and margin decisions for self-hosted or on-prem tiers.
• Upgrade sequencing: A patch-level fix with no API changes is low-risk to schedule; it belongs in the next maintenance window rather than a dedicated migration epic, and should be prioritized ahead of any feature that surfaces queue metrics to customers.

When to Consider This Package

Adopt when:

• You run Laravel/PHP workloads on multiple nodes and need queue processing that survives node loss without standing up Redis, RabbitMQ, or a cloud broker.
• Queue depth is a decision input — autoscaling, capacity planning, customer-facing status, or SLA reporting — and you need those numbers to be accurate cluster-wide.
• You operate in constrained or air-gapped environments where an embedded SQLite store is preferable to an external dependency.
• You need deterministic, cluster-wide queue administration (clear/purge) as part of tenant offboarding, environment resets, or incident recovery.
• Your team is comfortable operating a self-hosted Go-based queue component alongside the Laravel application and can own version pinning and rollout.

Look elsewhere when:

• You require vendor-managed durability guarantees, cross-region replication, or a support contract with an SLA.
• Your throughput profile exceeds what a single-writer SQLite backing store can absorb; high-fanout, high-churn queues are a better fit for a dedicated broker.
• You have no multi-node requirement — the replication complexity buys you nothing on a single host, and a simpler driver is easier to reason about.
• You cannot tolerate a self-hosted component in the critical path, or your platform standards mandate a managed queue service.
• You are mid-migration on queue infrastructure; layering a cluster-topology change onto an in-flight migration multiplies blast radius for no near-term gain.

How to Pitch It (Stakeholders)

For executives: This is a small patch to our queue infrastructure that fixes a real reliability defect — completed jobs were lingering on peer nodes and showing up as phantom backlog in monitoring. That made our queue dashboards lie, which is dangerous once we use them for alerting or autoscaling. The fix is contained, has no API or migration impact, and is a straightforward upgrade. It removes a blocker on any commitment we want to make about background job reliability across multiple servers, and it keeps us on a self-hosted queue that avoids a recurring managed-broker cost.

For engineering: v2.2.8 is a patch release addressing active-active replication correctness. Three changes: replication handlers now honor OpQDel tombstones by calling api.DeleteJob so remote-completed jobs are removed from local SQLite rather than orphaned in memory-deleted-but-persisted limbo; a new ClearQueueJobs() propagates OpQClear to wipe SQLite records cluster-wide; and handleReplicationConn drops a redundant duplicate push while ensuring replicated jobs are persisted consistently. No breaking changes, no config changes, no schema migration beyond normal table behavior. Recommended action: upgrade all nodes in the same window — mixed versions during rollout can still produce the orphaned-row condition on unpatched peers, so treat this as an all-nodes-or-nothing deploy and verify that backlog counts in Vigilance reconcile after the first replication cycle.