Jan 19, 2026
Coding

🚀 Laravel: Run Code After the Response (No Queues Needed)

After more than 10 years working as a full-stack developer, one thing I’ve learned is this: not every background task deserves a queue.

For a long time, we’ve treated queues as the default solution for anything that shouldn’t block a request. Logging, analytics, notifications, tracking user behavior, all of them usually meant:

  • Setting up a queue connection
  • Running workers
  • Managing retries and failures
  • Maintaining extra infrastructure

Sometimes it feels… a bit too much.

The Old Problem

Before Laravel 11, even for small, lightweight tasks, we had two bad choices:

  1. Run it synchronously
    → Slower response time, worse UX
  2. Push it to a queue
    → More complexity than the task actually needs

For example, something as simple as tracking a page view:

Analytics::track(request());

Do you really need Redis, Horizon, and a worker just for that?

Enter defer() in Laravel 11

Laravel 11 introduced a very elegant solution:

defer(fn () => Analytics::track(request()));

That’s it.

This line tells Laravel:

“Send the HTTP response first, then run this code.”

Why This Is a Big Deal

Here’s what happens under the hood:

  • ✅ The response is sent to the user immediately
  • ✅ The deferred code runs after the response
  • ✅ No queues
  • ✅ No workers
  • ✅ No extra setup

You get the benefits of async-like behavior without the infrastructure cost.

When Should You Use defer()?

defer() is perfect for lightweight, non-critical tasks, such as:

  • 📊 Analytics tracking
  • 📝 Logging
  • 🔔 Sending simple notifications
  • 📈 Metrics collection
  • 🧹 Small cleanup jobs

If the task:

  • Is fast
  • Doesn’t need retries
  • Isn’t business-critical

defer() is probably the right choice.

When Not to Use It

Queues still matter. Don’t replace them blindly.

Avoid defer() if:

  • The task is heavy or long-running
  • You need retries or failure handling
  • The job must be guaranteed to run
  • You’re processing large files or external APIs

In those cases, queues are still the correct tool.

Why I Like This Feature

As someone who has maintained systems for years, I really appreciate features that:

  • Reduce infrastructure
  • Simplify mental overhead
  • Keep code readable

defer() feels very “Laravel”:

Simple by default, powerful when needed.

Less boilerplate. Cleaner controllers. Faster responses.

Final Thoughts

Not every problem needs Redis.
Not every task needs a worker.

Sometimes, all you want is:

“Run this after the response, and don’t make my life harder.”

Laravel 11 delivers exactly that.

If you’re building APIs, dashboards, or SaaS products, defer() is a small feature that can quietly make your system cleaner and faster.

Happy coding 🚀

Thanks for reading!