Laravel at scale: what actually breaks first

"Laravel does not scale" is one of those claims that survives entirely on repetition. We run Laravel systems handling 40,000 concurrent users. Here is what actually goes wrong first, in the order we usually find it.

1. N+1 queries, every single time

Eloquent makes lazy loading so pleasant that you do it without noticing. A list page that renders 50 rows and touches one relation per row is 51 queries. Turn on Model::preventLazyLoading() outside production and the problem becomes impossible to ship rather than merely likely.

2. Doing work in the request

Sending an email, resizing an image, calling a third-party API — none of these belong in a web request. Queue them. The rule we apply: if it can fail independently of the response, it should run independently of the response.

3. Cache invalidation done wrong

Not the absence of caching — the presence of caching nobody can reason about. Our preferred pattern is a version integer on the parent record that forms part of every cache key. Bump the integer and an entire object graph's cache retires at once, with no key tracking and no stale reads.

4. The database, eventually

Real limits do arrive, and they are almost always missing indexes, then unbounded result sets, then write contention on a hot table. Read replicas help. Rewriting in Go, at the point most teams consider it, would not have.