Laravel Short Schedule Laravel Package

Product Decisions This Supports

• Real-time system monitoring: Schedule sub-second checks (e.g., API rate limits, system health metrics) without relying on external cron jobs or polling services.
• High-frequency data processing: Process time-sensitive data (e.g., IoT telemetry, live analytics) at intervals shorter than Laravel’s native scheduler (e.g., every 0.5s).
• Build vs. buy: Avoid reinventing a ReactPHP-based scheduler for sub-minute tasks, leveraging a battle-tested, open-source solution.
• Microservices orchestration: Trigger lightweight microservices or background jobs (e.g., cache invalidation, real-time notifications) with millisecond precision.
• Roadmap prioritization: Justify investment in infrastructure (e.g., Supervisor, Kubernetes) to support persistent, high-frequency tasks.
• Use cases:
  • Gaming: Sync player states or process in-game events (e.g., every 200ms).
  • FinTech: Execute low-latency transactions or fraud detection checks.
  • DevOps: Monitor server metrics (CPU, memory) and auto-scale resources dynamically.

When to Consider This Package

• Adopt if:

  • Your Laravel app requires sub-minute task execution (e.g., <1s intervals) that native schedule:run cannot handle.
  • You need non-blocking, parallel execution of commands (slow tasks shouldn’t delay others).
  • Your use case involves real-time constraints (e.g., live updates, high-frequency polling).
  • You’re already using ReactPHP or have experience with event loops (reduces learning curve).
  • You can dedicate a persistent process (via Supervisor/systemd) to run the scheduler 24/7.

• Look elsewhere if:

  • Your tasks can run at or above 1-minute intervals (use Laravel’s native scheduler).
  • You lack infrastructure to manage long-running processes (e.g., no Supervisor/Kubernetes).
  • Your commands are CPU/memory-intensive (risk of resource exhaustion; consider queue workers instead).
  • You need distributed locking across multiple servers (this package lacks built-in distributed coordination; pair with Redis or database locks).
  • Your team lacks PHP/ReactPHP expertise (debugging event loops can be complex).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us run critical background tasks at sub-second intervals—think real-time system checks, gaming leaderboards, or fraud detection—without overloading our servers. It’s like upgrading from a stopwatch to a nanosecond timer for automated processes. The cost? Minimal: just a persistent process (like a background service) to keep it running. We avoid vendor lock-in by using open-source tech, and it integrates seamlessly with our existing Laravel stack. Early adopters like [hypothetical company] use this to cut latency in [specific use case], saving [X] in operational costs."

For Engineering:

*"Laravel’s scheduler tops out at 1-minute intervals, but we need to run [specific task, e.g., ‘cache invalidation every 300ms’] without blocking other jobs. This package uses ReactPHP to spin up a non-blocking event loop that fires commands in parallel—no more sequential delays. Key benefits:

• Precision: Schedule tasks at 0.5s, 100ms, or custom intervals.
• Isolation: Each command runs in its own process; slow tasks won’t cascade.
• Constraints: Add when(), between(), or environments() filters like native scheduling.
• Production-ready: Works with Supervisor/systemd for persistence; supports memory leak mitigation via --lifetime. Tradeoff: Requires a dedicated process, but the tradeoff is worth it for [use case]. Let’s prototype this for [specific feature] and measure impact on [latency/metrics]."*

For DevOps:

*"This adds a ReactPHP-powered scheduler to run Artisan commands at sub-minute frequencies. To deploy:

1. Install via Composer: composer require spatie/laravel-short-schedule.
2. Configure in app/Console/Kernel.php (add shortSchedule() method).
3. Start the process in production: php artisan short-schedule:run (persist with Supervisor). Gotchas:

• Memory: Set --lifetime (e.g., 60) to auto-restart workers and avoid leaks.
• Logging: Commands run in detached processes; log output to a file or central system.
• Scaling: Each server needs its own instance (no built-in clustering). Pro tip: Pair with onOneServer() to avoid duplicate executions in multi-server setups."*