I've seen this happen more times than I can count: a developer wants to send a "Welcome" email after a user signs up, so they put the mail() function call right there in the registration controller. It works fine for one user. But then they decide to add a few more things—maybe a call to a third-party CRM API and a request to generate a PDF welcome pack. Suddenly, the user clicks "Sign Up" and their browser hangs for ten seconds. They think the site is broken and they click "Sign Up" three more times, triggering four sets of emails and API calls.

The Myth: Heavy Logic belongs in the HTTP Request

The misconception is that as long as your code is "fast enough" for a few users, it belongs in the request-response cycle. You might think, "I'll just optimize the API call," or "I'll use a faster mail server." But the problem isn't the speed of the individual task; it's the synchronous nature of the web request. If your PHP script is waiting for a response from an external server, your user is staring at a blank screen. You're tying the user's experience to the reliability of a third-party service. That's a recipe for a fragile application.

The Reality: Decoupling via a Job Queue

The fix is to stop trying to do the work during the request and instead record the intent to do the work. We call this decoupling. Instead of sending the email immediately, you insert a row into a database table—your "queue"—that says, "Hey, someone needs to send a welcome email to user #42." Then, the PHP script finishes instantly and tells the user "Success!" while a separate, independent PHP process (the worker) handles the actual heavy lifting in the background.

In a professional environment, I'd probably tell you to use Redis and something like Laravel Queue or Symfony Messenger. But to really understand how this works under the hood, we're going to build a primitive version using a MySQL table. It's a great way to visualize the "Producer/Consumer" pattern.

Here is the basic architecture we're aiming for:

• The Producer: Your web script. It doesn't send emails; it just writes a "job" to the database.
• The Job Table: A simple table with columns for the job_type, payload (usually JSON), and status (pending, processing, completed, failed).
• The Consumer (Worker): A PHP script run from the command line (CLI) that loops infinitely, looks for "pending" jobs, processes them, and marks them "completed".

// A glimpse of what the Producer does:
$job = [
    'type' => 'send_welcome_email',
    'payload' => json_encode(['user_id' => 42, 'email' => 'user@example.com']),
    'status' => 'pending'
];
$db->insert('jobs', $job);
// The user gets their response immediately!

One detail that often trips people up: atomic locking. If you run two worker scripts at once, they might both grab the same "pending" job at the exact same millisecond. I always recommend using a UPDATE jobs SET status = 'processing' WHERE id = X AND status = 'pending' query. If the affected row count is 1, that worker "owns" the job. If it's 0, someone else beat them to it.

📋 Practical Task

Build a Background Image Processing Queue

You are building a feature where users upload high-resolution profile pictures, and the system needs to generate three different thumbnail sizes. Doing this during the upload request is too slow.

Your Goal: Implement a minimal Job Queue system consisting of three parts:

1. The Schema: Create a SQL table named image_jobs with columns for id (AI), image_path (VARCHAR), status (ENUM: 'pending', 'processing', 'completed'), and created_at (TIMESTAMP).
2. The Dispatcher (Producer): Write a PHP script dispatch.php that simulates an upload by inserting a record into the image_jobs table with a dummy file path (e.g., 'uploads/profile_123.jpg').
3. The Worker (Consumer): Write a PHP CLI script worker.php that:
   • Polls the database for one 'pending' job.
   • Updates that job's status to 'processing' (ensuring no other worker can grab it).
   • Simulates a heavy image processing task using sleep(3).
   • Updates the status to 'completed'.
   • Loops back to check for more jobs, but sleeps for 1 second between checks to avoid murdering your CPU.

Testing your work: Run dispatch.php a few times to queue up jobs, then run php worker.php in your terminal and watch it process the images one by one.