Stop Overengineering Request-Level Caching in Laravel

Most Laravel developers are still overengineering request-level caching.

They use:

• class properties
• static variables
• manual flags
• unnecessary condition checks
• sometimes even Redis… for data that only lives within a single HTTP request

And every time I see it, I think:
Laravel already solved this problem for us.

The real problem isn’t performance

It’s unnecessary complexity.

The “Old” Way: More Code, More Noise

Let’s look at a pervasive pattern.

You want to avoid running the same query multiple times in one request, so you do something like this:

class UserService
{
    protected $users;

    public function getUsers()
    {
        if ($this->users === null) {
            $this->users = User::active()->get();
        }

        return $this->users;
    }
}

Or worse:

public function getUsers()
{
    static $users;

    if (!$users) {
        $users = User::active()->get();
    }

    return $users;
}

Yes, this works.

But ask yourself:

• Is this readable?
• Is this expressive?
• Is this what modern Laravel code should look like?

This kind of code adds mental overhead.
Now, future readers need to understand why the caching exists, where it resets, and how it behaves.

And this is still just request-level caching.

Laravel’s Built-In Solution (That Many Ignore)

Laravel gives us a clean, elegant solution:

$value = once(fn () => User::active()->get());

That’s it.

No Redis.
No files.
No configuration.
No extra state.

What once() does

• Executes the callback only once per request
• Caches the result in memory
• Automatically returns the cached value on subsequent calls

It’s perfect for:

• expensive queries
• service calls
• computed values
• anything that should only run once in a request lifecycle

And it reads beautifully.

Why This Is Senior-Level Code

Senior code isn’t about clever tricks.

It’s about:

• clarity
• intent
• trusting the framework

When I see once()I immediately know:

“This value is request-scoped, and I don’t need to think about it.”

No comments required.
No explanation needed.
The intent is obvious.

That’s the kind of code you want in a real production system.

Performance vs Simplicity

Here’s an uncomfortable truth:

Most Laravel apps don’t have performance problems.
They have complex problems.

Developers often:

• Optimize too early
• cache things that don’t need caching
• introduce a state that’s hard to reason about

Then six months later, nobody wants to touch that code.

Laravel is already fast enough for most use cases.
Your job as a developer is not to outsmart the framework; it’s to use it well.

When Not to Use once()

To be clear, once() It is not a global cache.

Don’t use it for:

• cross-request caching
• shared state
• expensive operations that should persist beyond one request

That’s what Redis, Memcached, or database caching is for.

once() shines when the scope is exactly one request.

At the end

If your Laravel code feels heavy, cluttered, or “clever”, pause for a moment.

The problem usually isn’t performance.
It’s unnecessary complexity.

Modern Laravel encourages:

• expressive code
• fewer moving parts
• trust in the framework

And sometimes, the most senior solution is just one line.