We took a Laravel API from 300 to 4,000 requests per second without rewriting it. The wins came from four layers: Octane workers, a layered cache, Horizon queues with separate supervisors, and read replicas with sticky writes. Here is the setup and the traps.
Our subscription platform had grown into a Laravel app with 400 models in one namespace, and every change risked breaking billing. We restructured it into modules with nwidart/laravel-modules: what a module owns, how modules talk through contracts and events, and where a module is the wrong tool.
We published an internal package to our private Packagist and every app failed to require it: could not find a version matching your minimum-stability (stable). The package had no tags, only a main branch, so Composer saw only dev-main. How stability flags, tags and branch aliases work.
After a Tuesday dnf update, image uploads on our Rocky Linux PHP servers returned 500s. A repository update moved ImageMagick to a new library version, and our hand-built imagick extension still linked to the old one. How we found it in dnf history, rolled back, pinned versions and made updates boring again.
Uploads and deploys failed with No space left on device while df showed 30% free. The filesystem had run out of inodes: a session directory held 9.6 million tiny files. How we found it with df -i, cleaned it without locking the box, and stopped it coming back.
Our Laravel export workers started at 70 MB and reached 1 GB after six hours, getting slower until Kubernetes killed them mid-job. An always-on query log, a static memo cache and whole-table loads were to blame. We fixed each and added worker limits.
Our orders export worked for every customer until one crossed 500,000 rows and PHP died with Allowed memory size exhausted. The endpoint loaded everything with get(), then built the CSV in memory. Streaming keyset chunks straight to the response fixed it at a flat 40 MB.
After moving our Symfony app to the official php-fpm image, median response time went from 38 ms to 121 ms with no code change. OPcache was never enabled in the new image, and checking it from the CLI hid the problem. Here is how we found it and tuned it.
Uploading a PDF larger than 1 MB failed with a vague error in our claims portal. Nginx returned 413, then PHP silently dropped files, then Laravel rejected them. Four layers each had their own size limit. Here is how we aligned them and tested every boundary.
Login and checkout forms started failing with 419 Page Expired the day we put two Laravel nodes behind a TLS-terminating load balancer. Untrusted proxy headers, secure cookies and file sessions on each node combined into one confusing error.
Our deploy ran composer update on a 2 GB server until the resolver ran out of memory. Raising the limit let the OOM killer take MySQL instead. Committing the lock file exposed a second bug: it had been resolved on PHP 8.4 for a PHP 8.2 server.
Our job board listing took 1.8 seconds and ran 312 queries per page. Blade was lazy loading company, tags and application counts for every row. We fixed it with with(), withCount() and made lazy loading throw in development.
After moving a PHP 7.4 app to PHP 8.3, our logs grew to 9 GB a day of null-to-string deprecation notices and filled a disk. We found the real call sites, fixed them by intent instead of blind casts, and blocked new ones in CI.
After moving our PHP app to a new Ubuntu 24.04 server, every page returned 502 Bad Gateway. Fixing socket ownership got us online, then traffic spikes brought the 502s back from an undersized FPM pool. Here is how we fixed both.