Jesus, esto va para ti.

Nos ha llegado que estas usando BullMQ para tus workers en vez de RabbitMQ. Buena eleccion – Redis como broker es rapido, simple, y no necesitas mantener un RabbitMQ aparte.

El caso es que en Cohete acabamos de montar infraestructura de mensajeria intercambiable. El skeleton tiene un MessageBus con dos implementaciones: una in-memory (ReactMessageBus) y otra con RabbitMQ (BunnieMessageBus). El dominio no sabe cual usa. Se cambia con una variable de entorno.

La interfaz es simple:

interface MessageBus
{
    public function publish(Message $message): void;
    public function subscribe(string $messageName, callable $listener): void;
}

Y aqui viene lo interesante: hacer un RedisMessageBus para Cohete es trivial. Existe clue/reactphp-redis, un cliente Redis async que encaja perfecto con nuestro event loop. La implementacion seria algo asi:

class RedisMessageBus implements MessageBus
{
    public function __construct(RedisClient $redis, RedisClient $subscriber)
    {
        // Un cliente para publicar, otro para subscribir
        // (Redis requiere conexiones separadas para Pub/Sub)
    }

    public function publish(Message $message): void
    {
        $this->redis->publish($message->name, json_encode($message->payload));
    }

    public function subscribe(string $messageName, callable $listener): void
    {
        $this->subscriber->subscribe($messageName);
        $this->subscriber->on('message', function ($channel, $payload) use ($listener) {
            $listener(json_decode($payload, true));
        });
    }
}

Unas 30 lineas. Mismo patron que RabbitMQ. Se activa con REDIS_HOST en el .env.

El puente con BullMQ

La gracia es que Redis Pub/Sub y BullMQ comparten el mismo Redis. El flujo seria:

Cohete (PHP async)
    | domain event: "order.created"
    | RedisMessageBus::publish()
    v
Redis (Pub/Sub o Streams)
    |
    v
Tu worker BullMQ (Node.js)
    | subscribe al canal
    | procesa el evento

Cohete publica domain events al Redis. Tus workers de BullMQ los consumen. Cada uno en su lenguaje, cada uno con su runtime, pero hablando por el mismo Redis.

Si en vez de Pub/Sub usamos Redis Streams (que es lo que BullMQ usa por debajo), la interop es total: Cohete escribe al stream con el formato que BullMQ espera, y tus workers lo consumen sin saber que el productor es PHP.

Que significa esto para ti

Que no tienes que cambiar nada de tu stack. Tus workers de BullMQ siguen siendo Node.js, siguen usando Redis, siguen procesando jobs como siempre. Cohete se encarga de publicar los eventos desde el lado PHP.

Si alguna vez quieres que tu app Cohete publique un evento y tu worker BullMQ lo procese (mandar un email, indexar en Elasticsearch, sincronizar con un tercero), el conector esta a 30 lineas de distancia.

El estado del skeleton

Por si no has visto el post de hoy: el skeleton de Cohete ya viene con API REST, Web Components, MySQL async, RabbitMQ, MCP para agentes de IA, y un CLAUDE.md que instruye a cualquier agente a construir features desde cero.

Redis seria el tercer bus. El patron esta montado, solo falta escribir la implementacion.

Cuando quieras, lo montamos.