Kamran Khan

The three questions are the right frame, especially the second one. In my experience the double run is rarely a scheduler bug, it is two workers both thinking they own the job. I now treat every scheduled job as if it will run twice, so I give it a unique key or a lock and make the work safe to repeat. The other change that helped me most was alerting when the expected run is missing, not just when a run fails, because a silent miss is the one nobody notices until a customer does.

This lines up with how I have chosen in client work. The question I ask first is who maintains it in year two, not which one ships the MVP faster. For a CRUD heavy SaaS with an admin side, Laravel has saved me the most time because auth, queues and scheduled jobs arrive as one tested set instead of five libraries I have to wire together. I would only pick NestJS when the team already writes TypeScript everywhere and real time features are central, not just nice to have.

I write it out each time, honestly. I tried a helper once and the failure message got vague about which level broke, so I kept the two asserts visible in each test. It is a bit repetitive, but when it fails I can see at a glance whether the relation is missing or the shape drifted.

The end-of-flow rule is the one I would underline. A webhook that returns 200 while skipping the work looks healthy to every other check, and I've only caught that kind of failure by watching for the completed event instead of the arrival. I also like the test-by-breaking step, because an alert I've never seen fire is just a hope. The habit that saved me most was writing the first action into the alert itself, so a quiet night doesn't turn into a confused search for which dashboard matters.

The diagnose-first order is the part I would keep. I have wasted more time clearing every cache than I ever saved, and checking whether the config is actually cached usually points straight at the stale file. The case that still catches me is a queue worker that was never restarted, because the web request looks fixed while jobs keep sending mail with the old host. I now treat an .env change as a deploy, not a quick server edit, and I do not consider it done until the worker restart is confirmed.

I do the same at every level, not just the top one. For a nested user I first assert that data.user is present, then I assert its exact keys, so a missing eager load fails loudly instead of letting the shape check pass over nothing. I apply that same presence-then-shape pair wherever a resource nests another resource, because that is where the quiet pass tends to hide. It adds a few lines per test, but I have caught more missing relations that way than I have caught extra fields.

One thing that bit me on a patch like this: reloading php-fpm is not the same as restarting it. A reload lets old workers finish their current requests, so a long lived upload can keep a vulnerable worker serving for minutes after you've called the box patched. For these I restart outright now, and accept the minute of dropped connections as the price.

Solid guide, and the canonical point is the one I'd underline twice. One gap I kept hitting on marketplace style sites: listing pages with ?sort=, ?filter= and ?page= in the query string. Each combination is a separate URL to Google, and a canonical that just mirrors the request tells Google every variant deserves indexing. I point filtered listings back to the clean base URL now, keeping only the base page canonical. Quietly the biggest crawl budget leak nobody warns you about.

One gotcha I'd add from a rollout like this: when you sync APP_KEY across the new boxes, every existing encrypted cookie dies at the same moment. We watched a chunk of users get bounced mid session during the cutover. If you're on Laravel 11, APP_PREVIOUS_KEYS lets you rotate instead of flipping the switch, so old cookies keep decrypting until they expire naturally. Worth calling out before the big sale, not after.

There is a sibling to this one on servers that upgrade PHP in place rather than rebuilding the image. apt installs the new binary and php -v says 8.5.12, but the running php-fpm pool keeps serving requests from the old one until the service restarts. My rule after any PHP bump is now: restart the FPM pool, then confirm the version through the request path, not just the CLI.