Queue Laravel Package

Product Decisions This Supports

• Scalable Background Processing: Enables asynchronous task execution (e.g., email sends, report generation, data processing) without blocking user-facing requests, improving system responsiveness and scalability.
• Decoupled Architecture: Supports microservices or modular monoliths by offloading non-critical tasks to a dedicated queue system, reducing coupling between services.
• Roadmap for Reliability: Justifies investment in a robust queue system to replace ad-hoc solutions (e.g., cron jobs, database polling) that may fail under load or lack observability.
• Build vs. Buy: Avoids reinventing a queue system (e.g., custom Redis/DB-based queues) by leveraging a battle-tested, PHP-native solution with Laravel integration.
• Multi-Tenancy / Per-Scope Queues (new in v0.11.0): Dynamically named subqueues with subqueuettl let you carve isolated queues per tenant, customer, or workflow and have them auto-expire. This supports product decisions around tenant isolation, noisy-neighbor containment, and bounded resource usage without hand-rolled partitioning logic.
• Type Safety as a Product Quality Lever (new in v0.11.0): Typed queue APIs reduce class-of-bug risk in job payloads and improve static analysis coverage — a meaningful input when weighing a smaller, typed, PHP-native package against a larger untyped ecosystem dependency.
• Backpressure Semantics (new in v0.11.0): Queue::put() can now return null when a bounded queue is full. This makes "reject work when saturated" an explicit, first-class product behavior rather than something bolted on — useful for protecting downstream services and for deciding which workloads may be shed under load.
• Use Cases:
  • High-volume batch processing (e.g., user onboarding flows, analytics pipelines).
  • Real-time notifications or alerts (e.g., Slack/Discord webhooks).
  • Long-running tasks (e.g., video encoding, PDF generation) with progress tracking.
  • Retry mechanisms for transient failures (e.g., API rate limits, network issues).
  • Ephemeral per-request or per-tenant queues that should age out on their own (new).

When to Consider This Package

Adopt if:

• Your Laravel app needs scalable, persistent task queues with retry/failure handling (e.g., >100 concurrent jobs or tasks >5s runtime).
• You require monitoring (e.g., job status, backlog size, failure rates) for operational visibility.
• Your stack already uses Tarantool (in-memory database) or you're open to adopting it for high-performance queue storage.
• You prioritize PHP-native solutions over external tools (e.g., RabbitMQ, Sidekiq) to reduce operational overhead.
• You are on PHP 8.2+ and can take tarantool/client ^0.11 — a hard requirement as of v0.11.0 that should be validated against your upgrade calendar before committing.
• You need scoped or self-expiring queues (multi-tenant isolation, per-workflow queues) — subqueuettl and dynamically named subqueues are the reason to pick this release specifically.
• You want typed job APIs that hold up under static analysis in a larger codebase.

Look elsewhere if:

• You need distributed task processing across multiple servers/clusters (consider RabbitMQ, Kafka, or Sidekiq).
• Your team lacks Tarantool expertise or prefers a more widely adopted queue backend (e.g., Redis with Laravel Queues).
• You require advanced features like delayed jobs, priority queues, or horizontal scaling out-of-the-box (evaluate Laravel Horizon or commercial tools). Note v0.11.0 does not add delayed or priority scheduling — subqueue TTL is expiry of the queue, not a delay primitive.
• You are pinned to PHP < 8.2 or tarantool/client < 0.11 — upgrading this release is effectively a runtime and dependency upgrade project, not a drop-in.
• Your workload is low-volume (<10 jobs/hour) and can use Laravel's built-in queue drivers (database, sync).

How to Pitch It (Stakeholders)

For Executives: "This package lets us offload time-consuming tasks (e.g., processing uploads, sending emails) from our web servers, making our app faster and more reliable. It's like adding a 'background worker' team that handles repetitive jobs while our main team focuses on user requests. Tarantool's in-memory database ensures low latency, and built-in monitoring helps us catch issues early. The newest release adds two things that matter commercially: isolated, self-cleaning queues per customer or workflow (so one noisy account can't degrade everyone else), and a defined 'reject when full' behavior so we degrade gracefully instead of falling over. Cost is a PHP 8.2 runtime upgrade and a client library bump — a scheduled maintenance item, not a new vendor."

For Engineering: *"tarantool/queue gives us a Laravel-native, Tarantool-backed queue system with:

• Job persistence: No lost tasks if workers crash.
• Retry logic: Automatic retries for transient failures (e.g., API timeouts).
• Monitoring: Track job progress, failures, and backlog via Laravel's queue tools.
• Performance: Tarantool's low-latency storage outperforms database queues for high-throughput workloads.

What v0.11.0 changes for us:

• Typed queue APIs: Stronger contracts for job payloads; better static analysis and fewer runtime surprises.
• subqueuettl + dynamically named subqueues: Per-tenant/per-workflow queues that expire automatically — replaces ad-hoc partitioning and manual cleanup.
• Queue::put() may return null on a full bounded queue: This is a behavioral change. Any call site that assumes a non-null return must be audited and made null-safe; treat it as backpressure, not an error, and decide the fallback (drop, retry, or surface to the user).
• Requirements: PHP 8.2+ and tarantool/client ^0.11 — verify both before bumping; the client major-minor jump may also pull transitive dependency changes.

Tradeoff: Requires Tarantool setup and now a PHP 8.2 floor, but avoids vendor lock-in to Redis/Sidekiq. Ideal for replacing cron jobs or custom queue solutions, and now viable for multi-tenant queue isolation."*