Torque Laravel Package

Product Decisions This Supports

• Build vs. buy / extend vs. adopt for queue infrastructure. The torque:bench command plus the bench/horizon-comparison/ reproduction kit convert "should we run Horizon or Torque?" from an opinion into a measurable evaluation on our own hardware and workload profile. That is the single most decision-relevant addition in v0.8.0: we can now produce internal numbers rather than citing vendor benchmarks.
• Capacity and cost planning. The seven workload profiles (cpu, io, async-io, fanout, mixed, payload-small, payload-large) map directly onto the axes that drive our infrastructure spend — concurrency, payload size, fan-out. The headline claims (up to 15x throughput on async I/O fan-out, ~95% lower memory at equivalent throughput) give us a hypothesis to validate per service, not a blanket justification.
• Roadmap sequencing for performance work. The igbinary serializer is opt-in and delivers ~67% throughput gain on payload-large with no measurable effect on small payloads. This tells us the optimization is a targeted lever, not a default switch — good signal for prioritizing where we invest in payload design versus infrastructure.
• Operability and incident-response requirements. JSON remaining the default (so redis-cli XRANGE keeps working during debugging) is a deliberate debuggability trade-off. The decode path sniffs the first byte, so flipping TORQUE_SERIALIZER is safe while workers run and in-flight messages drain. That is a genuine rollout-safety property we can factor into change-management policy.
• Architecture guidance for handler code. The README's "avoid the Eloquent trap" section formalizes something we would otherwise learn in production: blocking PDO calls in handlers destroy Fiber concurrency, and MysqlPool or pre-fetching at dispatch is the mitigation. This directly informs code-review standards and onboarding docs.
• Positioning of live job progress as a product differentiator. It is now a first-class, hero-level capability with a compatibility-table row and a per-job event timeline row. If our product or support tooling depends on job-level observability, that is a differentiating reason to evaluate Torque that Horizon does not answer the same way.

When to Consider This Package

Consider adoption when:

• Queue throughput or memory is an active constraint, particularly for async I/O fan-out workloads where the measured gap against queue:work (the engine under Horizon) is largest.
• You can benchmark on your own stack. torque:bench --use-running-master with --json=path (or --json=-) produces machine-readable output suitable for CI gating and before/after diffs. If you lack the appetite to run this even once, the performance case is unproven for you.
• Your handlers are Fiber-safe. You can avoid blocking PDO in handlers, or can adopt MysqlPool / dispatch-time pre-fetching. Teams with heavy synchronous Eloquent inside jobs will not realize the concurrency gains and should treat the compatibility table's Eloquent caveat as a first-class constraint.
• You need live job progress or per-job event timelines as a product or support requirement, not just queue depth metrics.
• You want to reproduce vendor claims before committing. The Horizon comparison kit and BENCHMARKS.md — including its explicit "what this benchmark does NOT measure" section — are rare and materially lower the risk of an evaluation.

Look elsewhere when:

• Peak payload throughput is not your bottleneck and small-payload performance is representative — igbinary showed no measurable difference there, so the serializer lever buys you nothing.
• You require JSON-only tooling and inspection workflows and are unwilling to accept a binary envelope; JSON stays the default, but adopting igbinary means redis-cli XRANGE output is no longer human-readable.
• You need per-stage latency breakdown today. BenchProbe is wired but the serialize / xadd / xreadgroup / unserialize / handle / xack breakdown is deferred to v1.1, and self-spawning workers from inside the bench command are also v1.1. If granular profiling is a hard requirement now, wait.
• You are standardized on Horizon's ecosystem and the switching cost outweighs a gap you have not measured on your own hardware.
• Your team cannot own a non-default queue subsystem. Torque is not the Laravel default path; the operational knowledge is yours to carry.

How to Pitch It (Stakeholders)

For executives: v0.8.0 turns Torque's performance story from assertion into evidence. The release ships a reproducible benchmark harness, a full comparison against Laravel's standard worker path (the engine Horizon runs on), and published methodology — including an explicit section on what the benchmark does not measure. Headline results are up to 15x throughput on async I/O fan-out and roughly 95% lower memory at equivalent throughput, with a ~67% gain on large payloads from an optional binary serializer. The practical ask is small: one engineer, one benchmarking cycle on our own hardware, producing a yes/no with numbers attached. Downside risk is contained — the serializer is opt-in, JSON remains the default, and format switching is safe mid-flight.

For engineering leadership: The release is deliberately conservative where it matters. JSON stays the default to preserve redis-cli debuggability; igbinary is opt-in and format detection is byte-sniffed so rolling the env var across a live fleet is safe. The bench command emits JSON for CI diffing, which means performance becomes a regression gate rather than a one-off study. Two real defects were found and fixed in this cycle — StreamJob::payload() was bypassing the new decode path (igbinary workers crashed on the readonly array property) and WorkerProcess::processMessage was validating with json_validate, silently dropping binary payloads as corrupt. Both were caught precisely because the Horizon comparison kit exercised a symmetric code path. That is a credibility signal about the testing approach, and a reminder that the igbinary path is young.

For engineering teams: Read the "avoid the Eloquent trap" section before writing handlers. Blocking PDO calls inside job handlers collapse Fiber concurrency and will erase the throughput case entirely; use MysqlPool or pre-fetch at dispatch. Known gaps to plan around: per-stage benchmark breakdown and self-spawning bench workers both land in v1.1, and torque:bench currently requires --use-running-master. Recommended first step is a single payload-large and fanout run against a representative worker to decide whether a broader evaluation is worth the time.