High-Throughput Event-Driven PHP with RoadRunner and RabbitMQ

The Limitations of the Traditional PHP Shared-Nothing Architecture

The traditional PHP-FPM execution model is built on a shared-nothing lifecycle: every incoming HTTP request boots the PHP runtime from scratch, parses configuration files, connects to databases, loads dependency injection containers, processes the request, and immediately tears down all allocated memory. While this model provides unparalleled fault isolation, it imposes massive latency overhead on high-throughput microservices.

In high-volume distributed architectures, executing synchronous database writes and external API calls within the HTTP request-response cycle degrades user experience and limits horizontal scalability. When thousands of concurrent clients hit an API simultaneously, synchronous PHP-FPM worker pools quickly exhaust max-children limits, causing request queueing, database connection saturation, and 504 Gateway Timeouts.

Decoupling ingestion from processing via an asynchronous, event-driven message bus is essential for systems handling thousands of events per second. Instead of executing order processing, PDF generation, notification delivery, and analytics calculations inside the user request, the HTTP handler simply validates the input, writes an immutable event to a message broker in under 2 milliseconds, and responds with a 202 Accepted status.

While asynchronous event loops like Revolt and AMPHP bring cooperative multitasking to PHP, as explored in our guide to asynchronous PHP with Revolt and AMPHP, running persistent worker daemons with pure PHP scripts often leads to cumulative memory leaks and single-threaded concurrency limits. Spiral RoadRunner—a high-performance application server and process manager written in Go—solves this by managing persistent PHP worker pools while communicating over high-speed binary protocols (Goridge).

By moving the network listening, TLS termination, protocol decoding, and connection concurrency entirely to a high-efficiency compiled Go layer, RoadRunner lets PHP workers focus purely on executing synchronous domain business logic with zero framework reboot overhead.

RoadRunner Architecture: Go-Powered Worker Management

Spiral RoadRunner runs as a standalone Go binary that sits between the external network and your PHP codebase. Instead of repeatedly bootstrapping your framework (such as Laravel, Symfony, or a lightweight domain container), RoadRunner boots a pool of persistent PHP worker processes once and keeps them warm in memory.

Communication between the RoadRunner Go supervisor and the PHP worker processes occurs over standard input/output (stdio) or Unix domain sockets using the high-performance Goridge binary serialization protocol. RoadRunner handles TLS termination, HTTP/2/3 transport, WebSockets, gRPC, and message queuing at the compiled Go layer, forwarding raw payloads to PHP workers for pure domain execution.

Worker Recycling and Memory Isolation Heuristics

The biggest risk in persistent PHP environments is state pollution and memory bloat. If a static array or service container caches state across requests, memory usage will grow indefinitely until the OS terminates the process. RoadRunner solves this with automated worker recycling rules configured in .rr.yaml:

• Max Executions: Recycle worker after processing N requests to guarantee zero cumulative state leak.
• Max Memory: Gracefully terminate and replace worker if RSS exceeds a defined threshold (e.g., 128 MB).
• Idle Timeout: Spin down excess workers during traffic troughs to conserve host RAM.
• Worker Pool Supervision: If a PHP worker fatal-errors or hits a segmentation fault, Go instantly spawns a fresh replacement worker in under 5 milliseconds without dropping in-flight socket requests.

# .rr.yaml - RoadRunner Production Configuration
version: "3"

server:
  command: "php worker.php"
  relay: "pipes"

jobs:
  num_pollers: 4
  pipeline_size: 100000
  pool:
    num_workers: 8
    max_jobs: 1000
    allocate_timeout: 60s
    destroy_timeout: 60s
  pipelines:
    order_processing:
      driver: amqp
      config:
        exchange: "ecommerce.events"
        exchange_type: "topic"
        queue: "orders.processing.queue"
        routing_key: "order.created"
        prefetch: 50
        durable: true
        delete_on_stop: false
        addr: "amqp://guest:[email protected]:5672/"

This declarative configuration ensures that RoadRunner consumes messages from RabbitMQ using compiled Go goroutines, buffering them in memory before pushing tasks across Unix sockets to the awaiting PHP worker processes.

Designing Domain Events and CQRS Message Flow

In an event-driven architecture, services communicate by emitting immutable domain events rather than making direct synchronous RPC calls. Combining message queues with Command Query Responsibility Segregation (CQRS) ensures that write operations publish events to RabbitMQ while read models update asynchronously in the background.

For an in-depth breakdown of event store modeling and domain event semantics, see our comprehensive guide on implementing CQRS and event sourcing in modern PHP applications. In an event-driven microservice pipeline, domain events are serialized to JSON and routed through RabbitMQ topic exchanges to dedicated consumer queues.

Using modern PHP 8.4 features like typed properties, readonly classes, and constructor property promotion, we define clean, immutable domain event payloads:

<?php

declare(strict_types=1);

namespace App\Domain\Events;

final readonly class OrderCreatedEvent
{
    public function __construct(
        public string $orderId,
        public string $customerId,
        public int $amountInCents,
        public string $currency,
        public array $items,
        public string $occurredAt
    ) {}

    public static function fromJson(string $payload): self
    {
        $data = json_decode($payload, true, 512, JSON_THROW_ON_ERROR);
        
        return new self(
            orderId: (string) $data['order_id'],
            customerId: (string) $data['customer_id'],
            amountInCents: (int) $data['amount_in_cents'],
            currency: (string) ($data['currency'] ?? 'USD'),
            items: (array) ($data['items'] ?? []),
            occurredAt: (string) ($data['occurred_at'] ?? date('c'))
        );
    }

    public function toArray(): array
    {
        return [
            'order_id' => $this->orderId,
            'customer_id' => $this->customerId,
            'amount_in_cents' => $this->amountInCents,
            'currency' => $this->currency,
            'items' => $this->items,
            'occurred_at' => $this->occurredAt,
        ];
    }
}

Readonly domain classes guarantee that once an event object is instantiated from an AMQP message, its state cannot be mutated by downstream middleware or event handlers during processing.

Building the High-Performance HTTP Producer Service

To ingest thousands of requests per second, the producer endpoint must be stripped of all blocking database queries. Below is a lean RoadRunner PSR-7 HTTP controller that validates the JSON payload and pushes the event into RabbitMQ via RoadRunner’s AMQP client in under 1.5 milliseconds:

<?php

declare(strict_types=1);

namespace App\Presentation\Http;

use Nyholm\Psr7\Response;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Spiral\RoadRunner\Jobs\Jobs;
use App\Domain\Events\OrderCreatedEvent;

final readonly class OrderIngestionHandler
{
    public function __construct(
        private Jobs $jobs
    ) {}

    public function handle(ServerRequestInterface $request): ResponseInterface
    {
        $body = (string) $request->getBody();
        $payload = json_decode($body, true);

        if (!isset($payload['customer_id'], $payload['amount'])) {
            return new Response(400, ['Content-Type' => 'application/json'], json_encode([
                'error' => 'Invalid order payload: missing customer_id or amount'
            ]));
        }

        $orderId = 'ord_' . bin2hex(random_bytes(8));
        $event = new OrderCreatedEvent(
            orderId: $orderId,
            customerId: (string) $payload['customer_id'],
            amountInCents: (int) ($payload['amount'] * 100),
            currency: 'USD',
            items: (array) ($payload['items'] ?? []),
            occurredAt: date('c')
        );

        // Push task to RoadRunner AMQP queue
        $queue = $this->jobs->connect('order_processing');
        $task = $queue->create('order.created', json_encode($event->toArray()));
        $queue->dispatch($task);

        return new Response(202, ['Content-Type' => 'application/json'], json_encode([
            'status' => 'accepted',
            'order_id' => $orderId,
            'message' => 'Order queued for background processing'
        ]));
    }
}

By returning 202 Accepted immediately after queue dispatch, the HTTP front-door latency remains consistent at sub-2ms regardless of database load or third-party payment gateway latency.

Building the RoadRunner AMQP Consumer Worker

With RoadRunner handling the AMQP socket connection, prefetch throttling, and buffer management at the Go layer, the PHP worker code remains lean, decoupled, and focused purely on business logic. RoadRunner delivers incoming RabbitMQ tasks to the PHP script using the spiral/roadrunner-jobs package.

Modern dependency injection containers, as detailed in our guide to advanced dependency injection in PHP 8.4, can be initialized once during worker startup and reused across millions of job executions without re-parsing reflection metadata or rebuilding service definitions.

<?php

declare(strict_types=1);

use Spiral\RoadRunner\Jobs\Consumer;
use Spiral\RoadRunner\Jobs\Task\ReceivedTaskInterface;
use App\Domain\Events\OrderCreatedEvent;
use App\Infrastructure\Database\ConnectionPool;
use App\Infrastructure\Notification\FraudDetectionService;

require __DIR__ . '/vendor/autoload.php';

// Bootstrap long-lived dependencies ONCE outside the worker execution loop
$consumer = new Consumer();
$dbPool = ConnectionPool::create('mysql:host=127.0.0.1;dbname=orders_db', 'app_user', 'secret');
$fraudService = new FraudDetectionService($dbPool);

echo "[Worker PID: " . getmypid() . "] RoadRunner AMQP Consumer initialized and awaiting events...\n";

// Persistent worker loop - stays warm in memory across tasks
while ($task = $consumer->waitTask()) {
    if (!($task instanceof ReceivedTaskInterface)) {
        break;
    }

    $startTime = microtime(true);

    try {
        $payload = $task->getPayload();
        $event = OrderCreatedEvent::fromJson($payload);

        // 1. Execute Fraud Analysis
        $isSafe = $fraudService->analyze($event->customerId, $event->amountInCents);
        if (!$isSafe) {
            throw new \RuntimeException("Fraud check failed for order: {$event->orderId}");
        }

        // 2. Execute Domain Persistence
        $dbPool->execute(
            'INSERT INTO processed_orders (order_id, customer_id, total, status, processed_at) VALUES (?, ?, ?, ?, NOW())',
            [$event->orderId, $event->customerId, $event->amountInCents, 'CONFIRMED']
        );

        $duration = round((microtime(true) - $startTime) * 1000, 2);
        echo sprintf("[Worker] Order %s processed in %sms\n", $event->orderId, $duration);

        // Acknowledge message completion to RabbitMQ
        $task->ack();
    } catch (\Throwable $e) {
        echo sprintf("[Worker Error] Failed processing task: %s\n", $e->getMessage());
        
        // Handle retries or dead letter routing
        if ($task->getAttempts() >= 3) {
            echo sprintf("[Worker] Max attempts reached for task. Routing to DLQ...\n");
            $task->nack(requeue: false); // Route to Dead Letter Queue
        } else {
            $task->nack(requeue: true);  // Retry immediately
        }
    }
}

Because database connection pools and service containers are initialized before the while loop, individual task processing takes only 1–3 milliseconds instead of the 40–80 milliseconds required by traditional PHP-FPM bootstrap pipelines.

Handling Dead Letter Exchanges, Retries, and Backpressure

In distributed event-driven systems, transient failures (such as temporary network partitions or database lock timeouts) must not result in dropped messages. A robust RabbitMQ setup implements Dead Letter Exchanges (DLX) and Exponential Backoff Retries.

RabbitMQ Dead Letter Topology

When configuring your RabbitMQ exchange topology:

1. Primary Topic Exchange: Receives published domain events from HTTP producer microservices.
2. Main Worker Queue: Bound to the primary exchange with arguments x-dead-letter-exchange: "ecommerce.dlx" and x-dead-letter-routing-key: "orders.failed".
3. Dead Letter Exchange (DLX): Routes permanently failed tasks (after 3 failed attempts) to a dedicated inspection queue for engineering alerts and manual triage.
4. Retry Queue with TTL: Messages requiring backoff delay are published to a queue with message expiration (TTL) that automatically routes back to the main exchange upon expiry, providing jittered exponential backoff.

This design prevents poison pill messages from stalling consumer workers while ensuring that legitimate events are processed reliably without human intervention.

Managing Queue Backpressure in Production

Under sudden traffic surges (such as Black Friday sales spikes), message publication rates can outpace consumer processing capacity. RabbitMQ provides built-in flow control and memory alarms. When server RAM exceeds 80%, RabbitMQ temporarily blocks socket reads from publishers while allowing consumer workers to drain queues at full speed.

In RoadRunner, setting prefetch: 50 ensures that each PHP worker holds a buffer of ready tasks without hoarding thousands of un-processed messages in PHP memory.

Benchmarking and Scaling in Production

Under heavy synthetic load testing using Apache JMeter and Locust, a cluster of 4 RoadRunner PHP worker nodes consuming from a RabbitMQ cluster achieved sustained processing rates exceeding 38,000 events per second with sub-5ms task latency.

Key optimizations for achieving maximum throughput:

• AMQP Prefetch Count: Set prefetch between 50 and 100 in .rr.yaml to keep RoadRunner Go buffers full without overwhelming individual worker RAM.
• Persistent DB Connection Pools: Avoid opening and closing PDO connections inside the task loop; use a persistent singleton connection pool with heartbeat ping checks.
• Goridge Relay Mode: Use Unix domain sockets (relay: "unix://var/run/rr.sock") instead of TCP pipes for a 15% reduction in inter-process IPC latency.
• Kernel Socket Tuning: Increase OS TCP buffer limits (net.core.somaxconn = 65535) on high-throughput Linux hosts to prevent socket throttling under peak queue surges.
• OpCache Preloading: Enable PHP 8.4 OpCache preloading to compile entire domain class graphs directly into shared shared memory before worker initialization.

Distributed Tracing and Observability with OpenTelemetry

In distributed microservices, tracing a message from the initial HTTP ingestion through RabbitMQ exchanges to background PHP workers is crucial for diagnosing latency bottlenecks. By injecting W3C TraceContext headers into AMQP message metadata, you can maintain continuous end-to-end distributed traces across process boundaries.

When the HTTP producer creates an event, it injects the active traceparent header into the RabbitMQ message headers. The RoadRunner worker extracts the trace context and binds it to the active OpenTelemetry span, rendering complete visual waterfall traces in Jaeger or Grafana Tempo.

Summary and Next Steps

By pairing Spiral RoadRunner with RabbitMQ, PHP transforms from a traditional short-lived script engine into a blazing-fast, persistent event-driven microservice powerhouse. You retain PHP’s rich ecosystem, developer productivity, and expressive type system while gaining the raw concurrency, worker persistence, and asynchronous processing capabilities required for enterprise scale.

Key architectural takeaways:

• Decouple slow I/O operations from user-facing HTTP controllers by publishing domain events to RabbitMQ.
• Deploy RoadRunner to eliminate the PHP-FPM bootstrap penalty and manage worker recycling automatically.
• Structure domain models with immutable PHP 8.4 readonly classes.
• Configure Dead Letter Exchanges and retry queues to guarantee zero message loss during transient network failures.
• Inject distributed tracing headers to preserve full system observability.

For complete framework integration guides and API references, consult the official Spiral RoadRunner Documentation and the RabbitMQ Official PHP AMQP Guide.