What is Pub/Sub (Publish-Subscribe)?

Pub/Sub (Publish-Subscribe) is a messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they're interested in. Publisher doesn't know who subscribes. Unlike queues (one consumer per message), pub/sub broadcasts to all subscribers. "User signed up" → 5 services all get notified. Common for event broadcasting, real-time notifications, microservice communication. Tools: Kafka, Redis Pub/Sub, Google Pub/Sub.

When Should You Use This?

Use pub/sub when one event should trigger multiple actions (user signup → email, analytics, CRM), when you want decoupled services (publisher doesn't know subscribers), for real-time notifications to many clients, or for event-driven microservices. Don't use when only one service should process message (use queue instead). Start simple, add pub/sub when you need fan-out.

Common Mistakes to Avoid

• •Confusing with queues—queues: one consumer. Pub/sub: many consumers
• •No message retention—subscribers offline miss messages, use durable subscriptions
• •Too many topics—topic explosion hard to manage, use message filtering instead
• •Synchronous pub/sub—defeats purpose, subscribers should process async
• •No dead letter—failed message processing gets lost

Real-World Examples

• •YouTube—New video published → subscribers get notification
• •Slack—Message posted → all connected clients in channel get update
• •Stock tickers—Price update → all subscribers get latest price
• •Microservices—"OrderPlaced" topic → inventory, shipping, analytics all subscribe