Concurrency Laravel Package

Product Decisions This Supports

• Latency-reduction roadmap bets. Any feature that must fan out to several independent backends in a single request — dashboard aggregation, search across multiple indexes, checkout summaries that call tax + shipping + inventory + payment, multi-provider rate lookups — is a candidate. This package converts "sum of N latencies" into "max of N latencies" without new infrastructure.
• Build vs. buy vs. shrug. It replaces hand-rolled curl_multi, proc_open wrappers, and bespoke parallel HTTP helpers that teams accumulate. It also removes a common justification for introducing a Node/Go BFF or an external orchestrator purely to parallelize request-time I/O.
• "Make it fast" vs. "make it durable" sequencing. This is a request-time latency tool, not a work-queue. It lets you ship a slow-but-correct synchronous feature now and defer durable async work (retries, backoff, replay, dead-letter) to a later queue investment — as long as you accept that in-flight work dies with the request.
• Cost and capacity decisions. A meaningful p95 drop on fan-out endpoints can defer vertical scaling, read-replica investment, or a caching tier. Conversely, forked processes multiply per-request memory, so the calculus is latency vs. headroom, not free.
• Use cases that justify a spike: multi-provider API fan-out, LLM/prompt fan-out with independent completions, report and export generation over independent partitions, batch notification dispatch inside an admin action, cache warming, health/readiness probes against several dependencies, image or asset variant generation.
• Architecture-appetite decisions. If this works, it reduces pressure to split services for parallelism alone. If it doesn't (long tasks, high task counts, strict durability), that negative result is itself a defensible argument for queue infrastructure or a worker tier.
• Rollout scoping. Because it's applied per call site, you can adopt it in internal tooling first, measure, then promote to customer-facing paths — a decision about blast radius, not a platform migration.

Caveat worth flagging in the decision record: the split repo's low star count reflects that it is a read-only subtree split of laravel/framework, not an independent project. Treat governance, security posture, and support as first-party Laravel core, and route diligence to framework docs and release notes rather than the split repo's activity.

When to Consider This Package

Consider it when:

• You're on a Laravel version that ships the Concurrency facade (11+) and deploy to Linux/macOS with pcntl/posix available.
• The work is embarrassingly parallel, independent, and short-lived — roughly 2–10 tasks, each sub-second to a couple of seconds, no ordering dependencies.
• You need per-request latency reduction, not durability. If the request dies, losing the work is acceptable.
• Partial failure is tolerable. runSafely() plus per-task fallbacks lets an endpoint degrade (return 4 of 5 sections) instead of erroring.
• You have memory headroom. Forked children inherit the parent's memory image; large payloads multiply fast.
• The team can debug forked children: reused DB connections must be reset, and logging/APM/error-reporting context, stdout, and transaction state do not automatically behave as in the parent.
• You want a sync driver in tests so parallel code paths stay deterministic in CI.

Look elsewhere when:

• Work must not be lost, must retry, or needs backoff, rate limiting, or visibility — use queues (Horizon/SQS) with rate limiters.
• Tasks are CPU-heavy, long-running, or numerous (dozens+); you'll exhaust processes and memory, and the queue/worker tier is the right home.
• You run on serverless/managed PHP runtimes, restricted shared hosting, or Windows dev/prod — forking support is absent or unreliable.
• You need cross-request orchestration, workflow state, or saga-style compensation — that's Temporal/Step Functions/queued chains.
• Closures would need to carry large serialized state or heavy container-resolved dependencies; the ergonomics and cost both degrade.
• You need hard guarantees against third-party quotas; parallelism is exactly the wrong tool for a rate-limited upstream.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a first-party, MIT-licensed component of the Laravel framework — no new services, no new vendors, no new deploy targets. It lets one endpoint run several independent tasks at the same time instead of one after another, which primarily improves p95 latency on pages that already call multiple backends. Adoption is per call site, so it's incremental and reversible: we pilot one endpoint, measure, and expand only if the numbers justify it. It is a latency tool, not a reliability tool — it complements, and does not replace, our queue infrastructure for work that must survive a failed request.

For engineering leads: A Concurrency facade (run, runSafely, defer, chaining/batching) with a process driver in production and a synchronous driver in tests. Integration cost is a few lines per call site; the real cost is operational hygiene — resetting database connections in children, ensuring logs and exception reporting attach correctly, and keeping task counts and memory bounded. Explicit non-goals: retries, durability, backpressure, cross-request state. Not supported on Windows or environments without pcntl.

The ask: A timeboxed spike on one high-fan-out endpoint, gated on a p95 improvement threshold and a memory ceiling, with a documented rollback (revert to sequential). If it clears, expand to the next two or three endpoints with the same measurement harness; if it doesn't, we've produced a concrete, costed argument for queue or worker-tier investment instead.