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.
When a small self-hosted service lost its disk, we restored the MySQL Docker volume from last night's tar backup, and MySQL refused to start with InnoDB corruption errors. The backup had been a file copy of a running database. How we recovered from an older dump, and the backup approach and restore drills we use now.
A 'random tip of the day' widget used ORDER BY RAND() LIMIT 1. It was fine at 5,000 rows and pinned the primary at 100 percent CPU at 1.4 million. Here is how we proved it and three random-row strategies that use an index instead.
Postgres and MySQL both speak SQL, but their internals push applications in different directions. We compare connections, MVCC and cleanup, clustered versus heap storage, and replication, and list what each difference changes in your code and operations.
Our game released 100 limited items at 20:00, and about 20,000 players tapped claim within seconds. 140 players received one. The endpoint checked remaining stock, then decremented it separately. How we proved the race and fixed it with an atomic conditional update, a constraint and a Redis gate.
Our MySQL primary hung and then aborted with the data volume at 100%. Binary logs had grown to 410 GB because a backfill tripled write volume while retention had been raised for a lagging replica. How we recovered, purged safely and stopped it recurring.
A one-second ALTER TABLE ... ALGORITHM=INSTANT hung for 11 minutes and every query on the table queued behind it. The blocker was a reporting job holding an open transaction. How we found it with performance_schema and made migrations fail fast.
Running the test suite inside our app container dropped every table in the development database. Docker Compose injected DB_DATABASE as a real environment variable, and phpunit.xml's env entries do not override existing variables. Here is the full precedence chain and three layers of defence.
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.
A slow accounting API pushed our PayPal webhook handler past the nginx timeout. PayPal saw a 504 and retried, while the first request was still running, and 41 wallets were topped up twice. Postmortem plus the idempotent design we moved to.
When MySQL sits at 100% CPU, the guilty query is rarely the slowest one; it is usually a fast query run millions of times. A practical sequence for finding it: the processlist for right now, performance_schema statement digests for the last hours, the sys schema for shortcuts, and pt-query-digest for slow log history.
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.
Stock updates from supplier feeds started failing with Deadlock found when trying to get lock during peak hours. Concurrent upsert batches touched the same unique keys in different orders under InnoDB next-key locking. Sorting, smaller batches and a retry fixed it.
Product reviews containing emoji failed with error 1366 after we upgraded MySQL to 8.0, while a nightly job quietly turned them into question marks. Legacy utf8mb3 tables, a wrong connection charset and an index length limit were all involved.