Booking System Accessibility: A Practical Guide for UK Businesses

Queue Systems in PHP: Why Background Processing Matters for User Experience

Modern web applications often need to handle tasks that take time to complete. Sending confirmation emails, generating invoices, syncing data with external services, and processing file uploads can all introduce delays that make users wait. Queue systems solve this by moving these time-consuming operations into the background, keeping your application responsive and your users happy.

When a user submits a booking on your website, they expect to see confirmation immediately. If your server spends three seconds generating a PDF report before showing the next page, that delay creates friction. Background processing via a queue keeps the HTTP response fast while the heavy work happens separately. Laravel Queue and Symfony Messenger are the standard PHP queue implementations, each offering reliable ways to defer work until after the initial response has been sent.

How PHP Queue Systems Work

A queue system separates the part of your application that accepts user requests from the part that does the actual work. When something needs to happen in the background, your application places a job message onto a queue. A separate worker process picks up that message and executes the associated task. The user gets their response right away, and the work completes without blocking anything else.

Three components make this work. The queue driver determines where job messages are stored. Laravel supports database, Redis, Beanstalkd, Amazon SQS, and synchronous drivers. Symfony Messenger works similarly, using transports that can be database-backed or use message brokers like AMQP. The job class defines what actually happens when the queue worker processes your task. Finally, the worker is a long-running process that monitors the queue and executes jobs as they arrive.

With Laravel, dispatching a job looks like this:

ProcessBookingConfirmation::dispatch($booking);

With Symfony Messenger, you create a message and dispatch it through the message bus:

$this->dispatch(new ProcessBookingConfirmation($bookingId));

Both approaches handle retries automatically when configured properly, and both can log failures to a database table for later inspection.

Common Background Tasks That Belong in a Queue

Not every task needs to run in the background, but several categories of work are particularly well-suited to queue processing. Understanding which tasks benefit most helps you decide where to invest the effort.

• Email delivery: Sending transactional emails like booking confirmations, password resets, or marketing newsletters. Email delivery involves network calls that can slow down responses if handled synchronously.
• PDF and document generation: Creating invoices, booking receipts, or reports often requires rendering templates and generating files, which can take several seconds depending on complexity.
• External API synchronization: Updating third-party systems, syncing inventory data, or pushing booking information to partner platforms. These operations involve network latency and external service availability.
• Data import and export: Processing uploaded CSV files, importing records from other systems, or generating large data exports. These tasks can consume significant server resources and memory.
• Webhook handling: Processing incoming webhooks from payment providers, booking platforms, or other services. Many webhooks require verification, processing, and response within tight timeframes.

Configuring Queue Workers for Production

Queue workers need to run continuously to pick up jobs as they arrive. In production, you run the worker as a background process that does not stop when you close your terminal. On Linux systems, a process supervisor like Supervisor handles this reliably, restarting the worker if it crashes and ensuring it starts automatically when the server boots.

A basic Supervisor configuration for a Laravel queue worker looks like this:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work redis --queue=high,default,low --sleep=3 --tries=3
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/log/worker.log
stopwaitsecs=3600

This configuration runs four worker processes, monitors the high-priority queue first, then the default queue, and finally the low-priority queue. The stopwaitsecs=3600 setting gives the worker time to finish its current job before shutting down if you need to deploy changes.

Symfony Messenger uses a similar approach. You configure one or more transports in your messenger.yaml file and run workers using the console command:

php bin/console messenger:consume async --limit=10

The --limit=10 option stops the worker after processing ten messages, which is useful for testing. In production, you run the worker as a supervised process that keeps running indefinitely.

Priority Queues and Job Routing

Not all background work has the same urgency. Payment confirmations and booking approvals should complete quickly, while routine notifications and analytics updates can wait. Queue systems let you route jobs to different queues based on their priority.

With Laravel, you can specify which queue a job belongs to when dispatching:

ProcessPayment::dispatch($payment)->onQueue('high');
SendNotification::dispatch($userId)->onQueue('low');

When starting your worker, you specify the queue order:

php artisan queue:work --queue=high,default,low

The worker checks the high queue first. If no jobs are waiting there, it processes the default queue. Only when both are empty does it work on low-priority jobs. This approach ensures that critical business operations complete before less time-sensitive tasks, even under heavy load.

Symfony Messenger handles this differently using transports. You define multiple transports in your configuration, each connected to a different queue or message broker, then route messages to the appropriate transport based on their type.

Job Failures, Retries, and Idempotency

Background jobs can fail for many reasons. Network timeouts, database connection issues, external service outages, or bugs in your code can all cause a job to throw an exception. A robust queue implementation handles this gracefully.

Laravel and Symfony both support automatic retries. You configure how many times a job should be attempted before being marked as failed. When a job exhausts its retry attempts, it moves to a failed jobs table where you can inspect what went wrong and retry it manually once the underlying issue is resolved.

Writing idempotent jobs makes retries safe. An idempotent job produces the same result regardless of how many times it runs. If your job sends a confirmation email, it should check whether the email was already sent before sending it again. If your job updates a database record, it should apply the update using conditions that prevent duplicate changes. This matters because the queue might retry a job that actually succeeded but timed out before reporting completion.

public function handle(): void
{
    $booking = Booking::find($this->bookingId);

    if ($booking->confirmationEmailSent()) {
        return; // Already sent, nothing to do
    }

    Mail::to($booking->customerEmail)->send(new BookingConfirmation($booking));
    $booking->markConfirmationEmailSent();
}

This pattern checks the current state before taking action, ensuring that retries do not cause duplicate emails or corrupted data.

Passing Data to Background Jobs

Queue jobs serialize the data they need and store it until execution. This has practical implications for what you pass to your job classes. Passing large objects or complex nested structures can create performance problems and, more importantly, stale data problems.

Imagine your job holds a reference to a Booking object when it is dispatched. If the queue is busy and the job sits waiting for ten minutes before executing, the booking data might have changed in the database. When the job finally runs, it works with outdated information. Passing the booking ID instead and reloading the booking at execution time solves this problem.

// Good: pass the ID, reload fresh data at execution time
ProcessBookingConfirmation::dispatch($booking->id);

// Risky: the object might be stale by execution time
ProcessBookingConfirmation::dispatch($booking);

Reloading data at execution time costs a database query, but it guarantees your job works with current information. The tradeoff is worth it for most background tasks.

Database Jobs Versus Dedicated Queue Servers

Getting started with queues does not require setting up complex infrastructure. Laravel and Symfony both support database-backed queues that store job records in your existing database. This approach works well for small to medium workloads and requires no additional services to maintain.

As your application grows, switching to a dedicated queue server like Redis or Beanstalkd improves performance. These systems are purpose-built for holding and delivering messages quickly, and they handle high volumes more efficiently than a database. Redis in particular is popular because many PHP applications already use it for caching, so adding it as a queue backend requires minimal new infrastructure.

Managed services like Amazon SQS offer another path. SQS handles the queue infrastructure entirely, with no servers to maintain and built-in redundancy. The tradeoff is per-message pricing that can add up under high volume, and slightly higher latency compared to a local Redis server.

Monitoring Queue Health in Production

Once your queue is handling real work, monitoring becomes important. You need to know if jobs are piling up faster than workers can process them, if jobs are failing repeatedly, or if workers have stopped running entirely.

Laravel Horizon provides a dashboard for monitoring queue jobs, worker status, and job throughput. It visualizes queue depth over time and lets you see which jobs are taking longest to complete. For Symfony applications, the Messenger dashboard in Symfony Cloud or third-party tools like Moni can provide similar visibility.

Basic monitoring you can implement without additional tools includes tracking the number of jobs in your failed_jobs table, alerting when queue depth exceeds a threshold, and logging whenever a job fails so you have records to investigate.

Queue Workers and Server Resources

Queue workers consume server resources. Each worker process uses CPU and memory while running your job code. Running too many workers on a limited server can cause resource contention that affects your web application performance.

Start conservatively. Run one worker process and monitor how it performs under normal load. If queue depth grows faster than workers can keep up, add another worker process. If memory usage becomes problematic, look at whether your job classes are holding too much data or whether you need to optimize the database queries they run.

For applications with widely varying workload, consider scaling workers dynamically based on queue depth. Cloud platforms like AWS can add worker instances when the queue fills up and terminate them during quiet periods, helping manage costs while maintaining responsiveness.

Testing Background Jobs

Background jobs contain business logic that needs testing just like any other part of your application. Laravel and Symfony both provide testing utilities for this. You can dispatch jobs synchronously during tests to verify they work correctly, assert that jobs were dispatched with specific data, and test job failure handling.

public function test_confirmation_email_is_sent_after_booking(): void
{
    Queue::fake();

    $booking = Booking::factory()->create();

    ProcessBookingConfirmation::dispatch($booking->id);

    Queue::assertPushed(ProcessBookingConfirmation::class, function ($job) use ($booking) {
        return $job->bookingId === $booking->id;
    });
}

Faking the queue lets you verify that the correct jobs are dispatched without actually running them. For integration tests, you can process jobs synchronously or use a test database that shares the queue tables with your test suite.

Integrating Queues with Webhook Processing

Many modern applications receive webhooks from external services. Payment gateways, booking platforms, and third-party APIs often send webhook notifications when events occur. Processing these webhooks synchronously during the HTTP request can be risky because the calling service may time out before your processing completes.

Placing webhook payloads onto a queue immediately after validation gives you several advantages. You can verify the webhook signature, acknowledge receipt quickly to the calling service, then process the actual work asynchronously. If processing fails, the queue retries the job while your application remains responsive. The guide to PHP webhook integration covers signature verification and duplicate handling in more detail.

Related practical reading

These related guides can help you connect this topic with the wider website, server, security, and support decisions around it.

• GraphQL in PHP vs REST: When GraphQL Is the Better Choice - useful background for related development decisions