Pub/Sub Pattern

TL;DR

Explanation

Publisher sends to a Topic/Channel — it doesn't know who's listening. Subscribers declare interest in topics. Broker delivers to all active subscribers. Implementations: Redis PUBLISH/SUBSCRIBE, Kafka topics, RabbitMQ fanout exchange, SNS+SQS (AWS), Google Pub/Sub. Difference from point-to-point queue: queue delivers to ONE consumer; pub/sub delivers to ALL subscribers. Use cases: event broadcasting (user registered → email + analytics + audit + recommendation all receive it), real-time feeds (dashboard updates). Fan-out: one event → many independent handlers. Redis pub/sub doesn't persist — subscribers miss messages while offline; use Redis Streams for durability.

Common Misconception

Why It Matters

Common Mistakes

• Using Redis SUBSCRIBE for durable events — messages are lost if subscriber is offline.
• Publishing events that are too granular — hundreds of tiny events create consumer overhead.
• Not considering message ordering when multiple publishers write to the same topic.

Code Examples

// Redis SUBSCRIBE — volatile, lost if offline:
$redis->subscribe(['user.registered'], function($redis, $channel, $msg) {
    sendWelcomeEmail($msg); // Missed if worker was down during publish
});

// Redis Streams — durable pub/sub:
$redis->xadd('user.events', '*', ['event' => 'registered', 'user_id' => $id]);

// Consumer group reads with acknowledgement:
$msgs = $redis->xreadgroup('email-group', 'worker-1', ['user.events' => '>']);
foreach ($msgs['user.events'] as $id => $fields) {
    sendWelcomeEmail($fields['user_id']);
    $redis->xack('user.events', 'email-group', $id);
}

References

• ↗ https://redis.io/docs/manual/pubsub/

Tags

Related Terms