System Design (HLD)Publish-Subscribe

Publish-Subscribe Pattern

LevelIntermediate

Duration75 mins

TopicPublish-Subscribe

5 / 5

Use Cases

Pub-Sub in the Wild

The publish-subscribe pattern isn't just an academic concept—it's the backbone of modern distributed systems at companies like Netflix, Uber, LinkedIn, and Shopify. Understanding where and why pub-sub excels helps you recognize opportunities to apply it in your own systems.

This page explores the most impactful use cases for pub-sub, examining real-world architectures and the specific characteristics that make pub-sub the right choice. We'll move from common patterns to advanced applications, building a comprehensive understanding of when and how to leverage this powerful paradigm.

What You Will Learn

By the end of this page, you will understand how pub-sub enables event-driven microservices, real-time analytics pipelines, CQRS architectures, notification systems, system integration, and IoT data ingestion. You'll see concrete examples and learn to identify when pub-sub is the right solution.

Event-Driven Microservices

The most foundational use case for pub-sub: enabling loosely coupled microservices that communicate through events rather than direct API calls. This architecture is the foundation of companies like Uber (using Kafka for ride events) and Shopify (using Kafka for order processing).

Converting Mermaid diagram...

Why Pub-Sub for Microservices

•Temporal decoupling: Services don't need to be available simultaneously. Order Service publishes; Payment Service processes when ready. No blocking, no timeouts.
•Team autonomy: Each team owns their domain and subscribes to events they care about. No coordination meetings to add new consumers.
•Resilience: If Payment Service goes down, orders queue up. No lost transactions. When it recovers, it processes the backlog.
•Evolution: Adding new functionality (loyalty points, fraud detection) requires only new subscriptions—no changes to Order Service.
•Observability: Event streams provide a complete audit trail of system activity.

event-driven-order-flow.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
// Event-Driven Order Processing Architecture
 
// Domain Events: The contract between services
interface OrderCreatedEvent {
  eventType: 'ORDER_CREATED';
  orderId: string;
  customerId: string;
  items: Array<{ sku: string; quantity: number; price: number }>;
  totalAmount: number;
  shippingAddress: Address;
  createdAt: string;
}
 
interface PaymentCompletedEvent {
  eventType: 'PAYMENT_COMPLETED';
  orderId: string;
  paymentId: string;
  amount: number;
  method: 'card' | 'paypal' | 'bank';
  completedAt: string;
}
 
interface FulfillmentStartedEvent {
  eventType: 'FULFILLMENT_STARTED';
  orderId: string;
  warehouseId: string;
  estimatedShipDate: string;
  trackingNumber?: string;
}
 
// Order Service: Publishes order events (knows nothing about consumers)
class OrderService {
  async createOrder(orderData: CreateOrderRequest): Promise<Order> {
    const order = await this.orderRepository.create(orderData);
    
    // Publish event - fire and forget
    await this.eventBus.publish('order-events', {
      eventType: 'ORDER_CREATED',
      orderId: order.id,
      customerId: order.customerId,
      items: order.items,
      totalAmount: order.totalAmount,
      shippingAddress: order.shippingAddress,
      createdAt: new Date().toISOString(),
    });
    
    return order; // Return immediately; downstream processing is async
  }
}
 
// Payment Service: Subscribes to order events, publishes payment events
class PaymentEventHandler {
  @Subscribe('order-events', { filter: "eventType = 'ORDER_CREATED'" })
  async handleOrderCreated(event: OrderCreatedEvent): Promise<void> {
    // Get saved payment method for customer
    const paymentMethod = await this.paymentMethodService.getDefault(event.customerId);
    
    // Process payment
    const payment = await this.paymentGateway.charge({
      customerId: event.customerId,
      amount: event.totalAmount,
      method: paymentMethod,
      orderId: event.orderId,
    });
    
    // Publish payment result
    await this.eventBus.publish('payment-events', {
      eventType: 'PAYMENT_COMPLETED',
      orderId: event.orderId,
      paymentId: payment.id,
      amount: event.totalAmount,
      method: paymentMethod.type,
      completedAt: new Date().toISOString(),
    });
  }
}
 
// Fulfillment Service: Subscribes to payment events
class FulfillmentEventHandler {
  @Subscribe('payment-events', { filter: "eventType = 'PAYMENT_COMPLETED'" })
  async handlePaymentCompleted(event: PaymentCompletedEvent): Promise<void> {
    const order = await this.orderService.getById(event.orderId);
    
    // Find optimal warehouse and reserve inventory
    const warehouse = await this.inventoryService.reserveAndAllocate(order.items);
    
    // Start fulfillment process
    await this.fulfillmentService.start({
      orderId: event.orderId,
      warehouseId: warehouse.id,
      items: order.items,
      shippingAddress: order.shippingAddress,
    });
  }
}

Choreography vs Orchestration

This example shows choreography: services react to events independently. For complex workflows with error handling and compensation, consider orchestration (e.g., saga pattern) where a central coordinator manages the flow. Pub-sub supports both patterns.

Real-Time Analytics Pipelines

Pub-sub is the de facto standard for feeding real-time analytics systems. Every user interaction, system event, and business transaction can flow through a pub-sub backbone to multiple analytics destinations simultaneously.

Converting Mermaid diagram...

Why Pub-Sub for Analytics:

Multi-destination delivery: Same events feed real-time dashboards, data warehouses, and ML pipelines—each subscription processes independently
Buffering: Spiky traffic smooths out; analytics consumers process at sustainable rates
Replay: Historical event replay enables backfilling, schema migrations, and new analytics development
Exactly-once processing: With proper checkpointing, avoid duplicate counting in aggregations

Common Analytics Event Schema (Example):

analytics-event-schema.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// Unified analytics event schema for multi-destination processing
 
interface AnalyticsEvent {
  // Event identification
  eventId: string;           // Unique, idempotent key
  eventType: string;         // page_view, click, purchase, etc.
  eventVersion: string;      // v1.2 - for schema evolution
  
  // Timing
  timestamp: string;         // ISO 8601, event occurrence time
  processedAt?: string;      // When ingested into pipeline
  
  // User context
  userId?: string;           // Authenticated user ID
  anonymousId: string;       // Device/session identifier
  sessionId: string;         // Current session
  
  // Device/environment
  platform: 'web' | 'ios' | 'android' | 'api';
  userAgent?: string;
  ipAddress?: string;        // May be hashed for privacy
  geolocation?: { country: string; region?: string; city?: string };
  
  // Event payload (varies by eventType)
  properties: Record<string, unknown>;
  
  // Context for analysis
  context: {
    page?: { url: string; title: string; referrer?: string };
    campaign?: { source: string; medium: string; name: string };
    experiment?: { name: string; variant: string };
  };
}
 
// Example: Page view event
const pageViewEvent: AnalyticsEvent = {
  eventId: 'evt_7k3j4h5g',
  eventType: 'page_view',
  eventVersion: 'v2.1',
  timestamp: '2024-01-15T14:30:00.123Z',
  userId: 'user_abc123',
  anonymousId: 'anon_xyz789',
  sessionId: 'sess_456def',
  platform: 'web',
  userAgent: 'Mozilla/5.0...',
  geolocation: { country: 'US', region: 'CA', city: 'San Francisco' },
  properties: {
    pageType: 'product',
    productId: 'prod_123',
    productCategory: 'electronics',
  },
  context: {
    page: { url: '/products/123', title: 'Widget Pro', referrer: '/search' },
    campaign: { source: 'google', medium: 'cpc', name: 'spring_sale' },
    experiment: { name: 'checkout_redesign', variant: 'B' },
  },
};

Schema Registry for Analytics

Use a schema registry (Confluent Schema Registry, AWS Glue) to manage analytics event schemas. This enables schema validation at publish time, automatic schema evolution, and compatibility checking when consumers upgrade. Critical for pipelines processing billions of events.

CQRS and Event Sourcing

Command Query Responsibility Segregation (CQRS) separates read and write models. Event Sourcing stores state changes as events rather than current state. Pub-sub is the natural connective tissue for both patterns, enabling write-side events to propagate to read-side projections.

Converting Mermaid diagram...

How It Works:

Commands (CreateOrder, UpdateInventory) are handled by domain aggregates
Events (OrderCreated, InventoryUpdated) are appended to an event store and published to the event bus
Projections subscribe to events and build/update read-optimized data stores
Queries read from projections, never from the event store directly

Why Pub-Sub Enables CQRS:

Multiple projections: One event stream, many specialized read models—each subscription builds a different view
Eventually consistent: Projections update asynchronously; acceptable for most read use cases
Replay: New projections can be built by replaying historical events
Isolation: Write-side performance unaffected by number of read models

cqrs-projection-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
// CQRS: Multiple read projections from one event stream
 
// Domain events (published after command handling)
type ProductEvent =
  | { type: 'PRODUCT_CREATED'; productId: string; name: string; price: number; category: string }
  | { type: 'PRODUCT_UPDATED'; productId: string; name?: string; price?: number }
  | { type: 'PRODUCT_STOCK_CHANGED'; productId: string; stockDelta: number }
  | { type: 'PRODUCT_DISCONTINUED'; productId: string };
 
// Projection 1: Product List (for catalog browsing)
class ProductListProjection {
  private db: PostgreSQL;
  
  async handleEvent(event: ProductEvent): Promise<void> {
    switch (event.type) {
      case 'PRODUCT_CREATED':
        await this.db.query(`
          INSERT INTO product_list (id, name, price, category, stock, active)
          VALUES ($1, $2, $3, $4, 0, true)
        `, [event.productId, event.name, event.price, event.category]);
        break;
        
      case 'PRODUCT_UPDATED':
        const updates = [];
        if (event.name) updates.push(`name = '${event.name}'`);
        if (event.price) updates.push(`price = ${event.price}`);
        await this.db.query(`
          UPDATE product_list SET ${updates.join(', ')} WHERE id = $1
        `, [event.productId]);
        break;
        
      case 'PRODUCT_STOCK_CHANGED':
        await this.db.query(`
          UPDATE product_list SET stock = stock + $1 WHERE id = $2
        `, [event.stockDelta, event.productId]);
        break;
        
      case 'PRODUCT_DISCONTINUED':
        await this.db.query(`
          UPDATE product_list SET active = false WHERE id = $1
        `, [event.productId]);
        break;
    }
  }
}
 
// Projection 2: Search Index (for full-text search)
class ProductSearchProjection {
  private elastic: ElasticsearchClient;
  
  async handleEvent(event: ProductEvent): Promise<void> {
    switch (event.type) {
      case 'PRODUCT_CREATED':
        await this.elastic.index({
          index: 'products',
          id: event.productId,
          body: {
            name: event.name,
            price: event.price,
            category: event.category,
            active: true,
          },
        });
        break;
        
      case 'PRODUCT_UPDATED':
        await this.elastic.update({
          index: 'products',
          id: event.productId,
          body: { doc: { name: event.name, price: event.price } },
        });
        break;
        
      case 'PRODUCT_DISCONTINUED':
        await this.elastic.update({
          index: 'products',
          id: event.productId,
          body: { doc: { active: false } },
        });
        break;
    }
  }
}
 
// Projection 3: Cache (for fast product lookups)
class ProductCacheProjection {
  private redis: RedisClient;
  
  async handleEvent(event: ProductEvent): Promise<void> {
    const key = `product:${event.productId}`;
    
    switch (event.type) {
      case 'PRODUCT_CREATED':
        await this.redis.hset(key, {
          name: event.name,
          price: event.price.toString(),
          category: event.category,
        });
        break;
        
      case 'PRODUCT_DISCONTINUED':
        await this.redis.del(key);
        break;
        
      // Stock and price updates handled similarly
    }
  }
}

Notification and Fanout Systems

When a single event needs to trigger multiple notification channels—email, push notification, SMS, in-app message, Slack—pub-sub provides the clean abstraction for multi-channel delivery without coupling the origin system to delivery mechanisms.

Converting Mermaid diagram...

Notification System Architecture:

Origin services publish notification requests (not channel-specific)
Notification Hub receives all notification requests on a topic
Notification Router looks up user preferences, applies templates, and dispatches to appropriate channels
Delivery Channels each have their own subscription, processing in parallel

Key Design Decisions:

User preferences per channel: Users opt in/out of each channel independently
Template engine centralization: Consistent brand voice across channels
Delivery status tracking: Each channel reports success/failure back to central tracking
Rate limiting per user: Prevent notification fatigue across channels
Priority queues: Urgent notifications (security alerts) skip the normal queue

notification-system.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// Multi-Channel Notification System with Pub-Sub
 
interface NotificationRequest {
  notificationId: string;
  type: 'order_shipped' | 'security_alert' | 'social_activity' | 'marketing';
  userId: string;
  priority: 'urgent' | 'high' | 'normal' | 'low';
  data: Record<string, unknown>;
  scheduledFor?: string; // Optional delayed delivery
}
 
// Origin: Order Service publishes notification request
async function notifyOrderShipped(order: Order): Promise<void> {
  await pubsub.publish('notification-requests', {
    notificationId: `notif_${order.id}_shipped`,
    type: 'order_shipped',
    userId: order.customerId,
    priority: 'high',
    data: {
      orderId: order.id,
      trackingNumber: order.trackingNumber,
      carrier: order.carrier,
      estimatedDelivery: order.estimatedDelivery,
      items: order.items.map(i => ({ name: i.name, quantity: i.quantity })),
    },
  });
  // Origin service done - doesn't know about emails, push, etc.
}
 
// Notification Router: Determines channels and dispatches
class NotificationRouter {
  @Subscribe('notification-requests')
  async handleNotification(request: NotificationRequest): Promise<void> {
    // 1. Look up user preferences
    const prefs = await this.userService.getNotificationPreferences(request.userId);
    const user = await this.userService.getById(request.userId);
    
    // 2. Apply template for each channel
    const template = this.templateEngine.getTemplate(request.type);
    
    // 3. Dispatch to enabled channels
    const dispatches: Promise<void>[] = [];
    
    if (prefs.email.enabled && this.shouldSend(prefs.email, request)) {
      dispatches.push(this.publishToChannel('email', {
        ...request,
        to: user.email,
        subject: template.emailSubject(request.data),
        body: template.emailBody(request.data),
      }));
    }
    
    if (prefs.push.enabled && user.pushTokens?.length > 0) {
      for (const token of user.pushTokens) {
        dispatches.push(this.publishToChannel('push', {
          ...request,
          token,
          title: template.pushTitle(request.data),
          body: template.pushBody(request.data),
          deepLink: template.deepLink(request.data),
        }));
      }
    }
    
    if (prefs.sms.enabled && request.priority === 'urgent') {
      dispatches.push(this.publishToChannel('sms', {
        ...request,
        phone: user.phone,
        message: template.smsMessage(request.data),
      }));
    }
    
    await Promise.all(dispatches);
  }
  
  private async publishToChannel(channel: string, payload: any): Promise<void> {
    await pubsub.publish(`notifications.${channel}`, payload);
  }
}
 
// Channel Handler: Email
class EmailNotificationHandler {
  @Subscribe('notifications.email')
  async handleEmail(notification: EmailNotification): Promise<void> {
    await this.sendGrid.send({
      to: notification.to,
      subject: notification.subject,
      html: notification.body,
    });
    
    await this.trackingService.recordDelivery({
      notificationId: notification.notificationId,
      channel: 'email',
      status: 'delivered',
    });
  }
}

System Integration and Event Bridge

When integrating disparate systems—legacy applications, third-party SaaS, partner systems, different cloud environments—pub-sub serves as a universal API that enables asynchronous, resilient communication without tight coupling.

Converting Mermaid diagram...

Event Bridge Pattern Benefits

•Protocol translation: Each system uses its native interface; adapters translate to canonical events
•Loose coupling: Systems don't communicate directly; the event bridge mediates all interactions
•Buffering: If a target system is slow or unavailable, events queue up safely
•Transformation: Adapters can enrich, filter, or transform events as needed
•Auditing: Central event bus provides complete visibility into cross-system communication
•Change isolation: Replacing or upgrading a system requires only adapter changes, not rewiring consumers

Canonical Event Model

Define a canonical event model that represents domain concepts (Customer, Order, Product) independent of any specific system's schema. Adapters translate between system-specific formats and canonical events. This prevents your event bus from becoming polluted with system-specific quirks.

event-bridge-adapter.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Event Bridge: Salesforce Adapter Example
 
// Canonical customer event (system-agnostic)
interface CustomerUpdatedEvent {
  eventType: 'CUSTOMER_UPDATED';
  source: string;
  customerId: string;
  timestamp: string;
  changes: {
    email?: string;
    phone?: string;
    address?: {
      street: string;
      city: string;
      state: string;
      country: string;
      postalCode: string;
    };
    segment?: 'enterprise' | 'midmarket' | 'smb';
  };
}
 
// Salesforce-specific webhook payload
interface SalesforceAccountUpdate {
  attributes: { type: 'Account'; url: string };
  Id: string;
  Name: string;
  BillingStreet: string;
  BillingCity: string;
  BillingState: string;
  BillingCountry: string;
  BillingPostalCode: string;
  Phone: string;
  Industry: string;
  Type: string; // Enterprise, Channel Partner, etc.
}
 
class SalesforceAdapter {
  // Inbound: Salesforce webhook → Canonical event
  async handleSalesforceWebhook(payload: SalesforceAccountUpdate): Promise<void> {
    const canonicalEvent: CustomerUpdatedEvent = {
      eventType: 'CUSTOMER_UPDATED',
      source: 'salesforce',
      customerId: this.mapSalesforceIdToCanonical(payload.Id),
      timestamp: new Date().toISOString(),
      changes: {
        phone: payload.Phone,
        address: {
          street: payload.BillingStreet,
          city: payload.BillingCity,
          state: payload.BillingState,
          country: payload.BillingCountry,
          postalCode: payload.BillingPostalCode,
        },
        segment: this.mapSalesforceTypeToSegment(payload.Type),
      },
    };
    
    await this.eventBus.publish('customer-events', canonicalEvent);
  }
  
  // Outbound: Canonical event → Salesforce API
  @Subscribe('customer-events', { filter: "source != 'salesforce'" })
  async syncToSalesforce(event: CustomerUpdatedEvent): Promise<void> {
    // Don't echo back events that originated from Salesforce
    const salesforceId = this.mapCanonicalIdToSalesforce(event.customerId);
    
    await this.salesforceClient.updateAccount(salesforceId, {
      Phone: event.changes.phone,
      BillingStreet: event.changes.address?.street,
      BillingCity: event.changes.address?.city,
      // ... map other fields
    });
  }
}

IoT Data Ingestion

Internet of Things (IoT) deployments generate massive volumes of telemetry data from distributed devices. Pub-sub provides the scalable ingestion layer that buffers, routes, and processes this firehose of data.

Converting Mermaid diagram...

IoT Ingestion Challenges Solved by Pub-Sub:

Scale: Millions of devices, billions of events/day. Pub-sub's horizontal scaling handles the volume.
Buffering: Devices may send bursts; pub-sub smooths traffic for downstream consumers.
Device independence: Devices publish without knowing consumers; new analytics don't require device updates.
Multi-speed consumers: Real-time alerting needs millisecond latency; batch analytics processes hourly. Same stream, different speeds.
Replay for training: ML models train on historical data replayed from the event log.

iot-telemetry-processing.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
// IoT Telemetry Processing Pipeline
 
interface TelemetryEvent {
  deviceId: string;
  deviceType: 'sensor' | 'vehicle' | 'meter' | 'wearable';
  timestamp: string;
  readings: {
    metric: string;
    value: number;
    unit: string;
  }[];
  metadata: {
    firmwareVersion: string;
    batteryLevel?: number;
    signalStrength?: number;
  };
}
 
// Stream Processor: Real-time aggregation and routing
class TelemetryProcessor {
  @Subscribe('telemetry.raw')
  async processTelemetry(event: TelemetryEvent): Promise<void> {
    // Enrich with device metadata
    const device = await this.deviceRegistry.get(event.deviceId);
    
    // Check for anomalies
    for (const reading of event.readings) {
      const threshold = await this.thresholdService.get(device.type, reading.metric);
      
      if (reading.value > threshold.critical) {
        // Publish to alerts topic
        await this.eventBus.publish('alerts.critical', {
          alertId: generateId(),
          deviceId: event.deviceId,
          metric: reading.metric,
          value: reading.value,
          threshold: threshold.critical,
          severity: 'critical',
          timestamp: event.timestamp,
        });
      }
    }
    
    // Aggregate for time-series storage
    const aggregatedReading = {
      deviceId: event.deviceId,
      timestamp: event.timestamp,
      readings: event.readings.reduce((acc, r) => ({
        ...acc,
        [r.metric]: r.value,
      }), {}),
    };
    
    await this.timeSeriesDb.write(aggregatedReading);
    
    // Publish processed event for other consumers
    await this.eventBus.publish('telemetry.processed', {
      ...event,
      deviceMeta: device,
      processedAt: new Date().toISOString(),
    });
  }
}
 
// Anomaly Detection: Subscribes to processed telemetry
class AnomalyDetector {
  @Subscribe('telemetry.processed')
  async detectAnomalies(event: TelemetryEvent): Promise<void> {
    // Run ML model for predictive maintenance
    const prediction = await this.mlModel.predict({
      deviceId: event.deviceId,
      readings: event.readings,
      historicalAvg: await this.getHistoricalAverages(event.deviceId),
    });
    
    if (prediction.maintenanceNeeded && prediction.confidence > 0.85) {
      await this.eventBus.publish('maintenance.predicted', {
        deviceId: event.deviceId,
        predictedFailureDate: prediction.estimatedFailureDate,
        confidence: prediction.confidence,
        recommendedAction: prediction.action,
      });
    }
  }
}

When NOT to Use Pub-Sub

Pub-sub is powerful, but it's not the right tool for every situation. Understanding its limitations helps you avoid misapplying the pattern.

Scenarios Where Pub-Sub May Not Be Ideal

•Request-Response needed: If the caller needs an immediate response to proceed (synchronous workflow), direct API calls may be simpler. Pub-sub is fire-and-forget; faking request-response adds complexity.
•Low message volume: For a handful of messages per hour between two services, the overhead of message broker infrastructure may not be justified. Direct calls work fine.
•Strong transactional requirements: If a saga's compensating transactions must execute synchronously with guaranteed outcomes, carefully orchestrated calls may be clearer than event choreography.
•Ordering MUST be global: If events must be processed in strict global order (not just per-entity order), pub-sub's partitioning makes this hard. Consider a single writer or database-based queue.
•Latency critical (<5ms): Message brokers add latency (typically 10-100ms). For ultra-low-latency needs (trading, gaming), direct communication or shared memory may be required.
•Simple single-consumer queue: If you just need to distribute work to a pool of workers (not fan-out), a simple queue (SQS, RabbitMQ in queue mode) is simpler than pub-sub.

Choosing Communication Patterns
Scenario	Recommended Pattern	Why
Get user profile by ID	Synchronous API	Need immediate response; simple query
Process order asynchronously	Pub-Sub	Multiple consumers; resilience needed
Distribute image resize jobs	Message Queue	Single consumer group; work distribution
Real-time game state updates	WebSocket / direct	Sub-millisecond latency required
Batch ETL processing	Pub-Sub (replay)	Large volume; replay for recovery
Two-phase commit transaction	Orchestrated calls	Atomic guarantee required

Hybrid Architectures

Most real systems use multiple patterns. Synchronous APIs for user-facing queries, pub-sub for cross-service integration, queues for background job processing. Choose the right tool for each specific communication need rather than forcing everything into one pattern.

Summary: Pub-Sub Use Cases

We've explored the major production use cases for publish-subscribe messaging. Let's consolidate the key insights:

Key Takeaways

•Event-driven microservices: Pub-sub enables loosely coupled services that communicate through domain events, enabling team autonomy and system resilience.
•Real-time analytics: The same event stream feeds dashboards, data warehouses, and ML pipelines simultaneously, with independent processing speeds.
•CQRS and event sourcing: One event stream projects to many read-optimized views, with replay capability for new projections and debugging.
•Multi-channel notifications: Decouple notification triggers from delivery channels; user preferences determine where notifications route.
•System integration: Event bridges connect disparate systems with canonical events, enabling loose coupling and protocol translation.
•IoT ingestion: Handle massive device telemetry with buffering, multi-speed consumers, and replay for ML training.
•Know when NOT to use it: Request-response needs, ultra-low latency, simple queuing, and strong transactions may call for other patterns.

Module Complete:

You've now completed the comprehensive study of publish-subscribe messaging. From the foundational concepts of one-to-many messaging through topics, subscriptions, fan-out patterns, filtering, and real-world use cases, you have the knowledge to design and implement robust pub-sub architectures for any scale.

Module Complete

Congratulations! You've mastered the publish-subscribe pattern—one of the most important building blocks of modern distributed systems. From one-to-many messaging to topics and subscriptions, fan-out patterns, message filtering, and production use cases, you now have the conceptual foundation to design event-driven architectures that scale.

5 / 5

Loading learning content...

System Design (HLD)Publish-Subscribe

Publish-Subscribe Pattern

LevelIntermediate

Duration75 mins

TopicPublish-Subscribe

5 / 5

Use Cases

Pub-Sub in the Wild

What You Will Learn

Event-Driven Microservices

Converting Mermaid diagram...

Why Pub-Sub for Microservices

•Temporal decoupling: Services don't need to be available simultaneously. Order Service publishes; Payment Service processes when ready. No blocking, no timeouts.
•Team autonomy: Each team owns their domain and subscribes to events they care about. No coordination meetings to add new consumers.
•Resilience: If Payment Service goes down, orders queue up. No lost transactions. When it recovers, it processes the backlog.
•Evolution: Adding new functionality (loyalty points, fraud detection) requires only new subscriptions—no changes to Order Service.
•Observability: Event streams provide a complete audit trail of system activity.

event-driven-order-flow.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
// Event-Driven Order Processing Architecture
 
// Domain Events: The contract between services
interface OrderCreatedEvent {
  eventType: 'ORDER_CREATED';
  orderId: string;
  customerId: string;
  items: Array<{ sku: string; quantity: number; price: number }>;
  totalAmount: number;
  shippingAddress: Address;
  createdAt: string;
}
 
interface PaymentCompletedEvent {
  eventType: 'PAYMENT_COMPLETED';
  orderId: string;
  paymentId: string;
  amount: number;
  method: 'card' | 'paypal' | 'bank';
  completedAt: string;
}
 
interface FulfillmentStartedEvent {
  eventType: 'FULFILLMENT_STARTED';
  orderId: string;
  warehouseId: string;
  estimatedShipDate: string;
  trackingNumber?: string;
}
 
// Order Service: Publishes order events (knows nothing about consumers)
class OrderService {
  async createOrder(orderData: CreateOrderRequest): Promise<Order> {
    const order = await this.orderRepository.create(orderData);
    
    // Publish event - fire and forget
    await this.eventBus.publish('order-events', {
      eventType: 'ORDER_CREATED',
      orderId: order.id,
      customerId: order.customerId,
      items: order.items,
      totalAmount: order.totalAmount,
      shippingAddress: order.shippingAddress,
      createdAt: new Date().toISOString(),
    });
    
    return order; // Return immediately; downstream processing is async
  }
}
 
// Payment Service: Subscribes to order events, publishes payment events
class PaymentEventHandler {
  @Subscribe('order-events', { filter: "eventType = 'ORDER_CREATED'" })
  async handleOrderCreated(event: OrderCreatedEvent): Promise<void> {
    // Get saved payment method for customer
    const paymentMethod = await this.paymentMethodService.getDefault(event.customerId);
    
    // Process payment
    const payment = await this.paymentGateway.charge({
      customerId: event.customerId,
      amount: event.totalAmount,
      method: paymentMethod,
      orderId: event.orderId,
    });
    
    // Publish payment result
    await this.eventBus.publish('payment-events', {
      eventType: 'PAYMENT_COMPLETED',
      orderId: event.orderId,
      paymentId: payment.id,
      amount: event.totalAmount,
      method: paymentMethod.type,
      completedAt: new Date().toISOString(),
    });
  }
}
 
// Fulfillment Service: Subscribes to payment events
class FulfillmentEventHandler {
  @Subscribe('payment-events', { filter: "eventType = 'PAYMENT_COMPLETED'" })
  async handlePaymentCompleted(event: PaymentCompletedEvent): Promise<void> {
    const order = await this.orderService.getById(event.orderId);
    
    // Find optimal warehouse and reserve inventory
    const warehouse = await this.inventoryService.reserveAndAllocate(order.items);
    
    // Start fulfillment process
    await this.fulfillmentService.start({
      orderId: event.orderId,
      warehouseId: warehouse.id,
      items: order.items,
      shippingAddress: order.shippingAddress,
    });
  }
}

Choreography vs Orchestration

Real-Time Analytics Pipelines

Converting Mermaid diagram...

Why Pub-Sub for Analytics:

Multi-destination delivery: Same events feed real-time dashboards, data warehouses, and ML pipelines—each subscription processes independently
Buffering: Spiky traffic smooths out; analytics consumers process at sustainable rates
Replay: Historical event replay enables backfilling, schema migrations, and new analytics development
Exactly-once processing: With proper checkpointing, avoid duplicate counting in aggregations

Common Analytics Event Schema (Example):

analytics-event-schema.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// Unified analytics event schema for multi-destination processing
 
interface AnalyticsEvent {
  // Event identification
  eventId: string;           // Unique, idempotent key
  eventType: string;         // page_view, click, purchase, etc.
  eventVersion: string;      // v1.2 - for schema evolution
  
  // Timing
  timestamp: string;         // ISO 8601, event occurrence time
  processedAt?: string;      // When ingested into pipeline
  
  // User context
  userId?: string;           // Authenticated user ID
  anonymousId: string;       // Device/session identifier
  sessionId: string;         // Current session
  
  // Device/environment
  platform: 'web' | 'ios' | 'android' | 'api';
  userAgent?: string;
  ipAddress?: string;        // May be hashed for privacy
  geolocation?: { country: string; region?: string; city?: string };
  
  // Event payload (varies by eventType)
  properties: Record<string, unknown>;
  
  // Context for analysis
  context: {
    page?: { url: string; title: string; referrer?: string };
    campaign?: { source: string; medium: string; name: string };
    experiment?: { name: string; variant: string };
  };
}
 
// Example: Page view event
const pageViewEvent: AnalyticsEvent = {
  eventId: 'evt_7k3j4h5g',
  eventType: 'page_view',
  eventVersion: 'v2.1',
  timestamp: '2024-01-15T14:30:00.123Z',
  userId: 'user_abc123',
  anonymousId: 'anon_xyz789',
  sessionId: 'sess_456def',
  platform: 'web',
  userAgent: 'Mozilla/5.0...',
  geolocation: { country: 'US', region: 'CA', city: 'San Francisco' },
  properties: {
    pageType: 'product',
    productId: 'prod_123',
    productCategory: 'electronics',
  },
  context: {
    page: { url: '/products/123', title: 'Widget Pro', referrer: '/search' },
    campaign: { source: 'google', medium: 'cpc', name: 'spring_sale' },
    experiment: { name: 'checkout_redesign', variant: 'B' },
  },
};

Schema Registry for Analytics

CQRS and Event Sourcing

Converting Mermaid diagram...

How It Works:

Commands (CreateOrder, UpdateInventory) are handled by domain aggregates
Events (OrderCreated, InventoryUpdated) are appended to an event store and published to the event bus
Projections subscribe to events and build/update read-optimized data stores
Queries read from projections, never from the event store directly

Why Pub-Sub Enables CQRS:

Multiple projections: One event stream, many specialized read models—each subscription builds a different view
Eventually consistent: Projections update asynchronously; acceptable for most read use cases
Replay: New projections can be built by replaying historical events
Isolation: Write-side performance unaffected by number of read models

cqrs-projection-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
// CQRS: Multiple read projections from one event stream
 
// Domain events (published after command handling)
type ProductEvent =
  | { type: 'PRODUCT_CREATED'; productId: string; name: string; price: number; category: string }
  | { type: 'PRODUCT_UPDATED'; productId: string; name?: string; price?: number }
  | { type: 'PRODUCT_STOCK_CHANGED'; productId: string; stockDelta: number }
  | { type: 'PRODUCT_DISCONTINUED'; productId: string };
 
// Projection 1: Product List (for catalog browsing)
class ProductListProjection {
  private db: PostgreSQL;
  
  async handleEvent(event: ProductEvent): Promise<void> {
    switch (event.type) {
      case 'PRODUCT_CREATED':
        await this.db.query(`
          INSERT INTO product_list (id, name, price, category, stock, active)
          VALUES ($1, $2, $3, $4, 0, true)
        `, [event.productId, event.name, event.price, event.category]);
        break;
        
      case 'PRODUCT_UPDATED':
        const updates = [];
        if (event.name) updates.push(`name = '${event.name}'`);
        if (event.price) updates.push(`price = ${event.price}`);
        await this.db.query(`
          UPDATE product_list SET ${updates.join(', ')} WHERE id = $1
        `, [event.productId]);
        break;
        
      case 'PRODUCT_STOCK_CHANGED':
        await this.db.query(`
          UPDATE product_list SET stock = stock + $1 WHERE id = $2
        `, [event.stockDelta, event.productId]);
        break;
        
      case 'PRODUCT_DISCONTINUED':
        await this.db.query(`
          UPDATE product_list SET active = false WHERE id = $1
        `, [event.productId]);
        break;
    }
  }
}
 
// Projection 2: Search Index (for full-text search)
class ProductSearchProjection {
  private elastic: ElasticsearchClient;
  
  async handleEvent(event: ProductEvent): Promise<void> {
    switch (event.type) {
      case 'PRODUCT_CREATED':
        await this.elastic.index({
          index: 'products',
          id: event.productId,
          body: {
            name: event.name,
            price: event.price,
            category: event.category,
            active: true,
          },
        });
        break;
        
      case 'PRODUCT_UPDATED':
        await this.elastic.update({
          index: 'products',
          id: event.productId,
          body: { doc: { name: event.name, price: event.price } },
        });
        break;
        
      case 'PRODUCT_DISCONTINUED':
        await this.elastic.update({
          index: 'products',
          id: event.productId,
          body: { doc: { active: false } },
        });
        break;
    }
  }
}
 
// Projection 3: Cache (for fast product lookups)
class ProductCacheProjection {
  private redis: RedisClient;
  
  async handleEvent(event: ProductEvent): Promise<void> {
    const key = `product:${event.productId}`;
    
    switch (event.type) {
      case 'PRODUCT_CREATED':
        await this.redis.hset(key, {
          name: event.name,
          price: event.price.toString(),
          category: event.category,
        });
        break;
        
      case 'PRODUCT_DISCONTINUED':
        await this.redis.del(key);
        break;
        
      // Stock and price updates handled similarly
    }
  }
}

Notification and Fanout Systems

Converting Mermaid diagram...

Notification System Architecture:

Origin services publish notification requests (not channel-specific)
Notification Hub receives all notification requests on a topic
Notification Router looks up user preferences, applies templates, and dispatches to appropriate channels
Delivery Channels each have their own subscription, processing in parallel

Key Design Decisions:

User preferences per channel: Users opt in/out of each channel independently
Template engine centralization: Consistent brand voice across channels
Delivery status tracking: Each channel reports success/failure back to central tracking
Rate limiting per user: Prevent notification fatigue across channels
Priority queues: Urgent notifications (security alerts) skip the normal queue

notification-system.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// Multi-Channel Notification System with Pub-Sub
 
interface NotificationRequest {
  notificationId: string;
  type: 'order_shipped' | 'security_alert' | 'social_activity' | 'marketing';
  userId: string;
  priority: 'urgent' | 'high' | 'normal' | 'low';
  data: Record<string, unknown>;
  scheduledFor?: string; // Optional delayed delivery
}
 
// Origin: Order Service publishes notification request
async function notifyOrderShipped(order: Order): Promise<void> {
  await pubsub.publish('notification-requests', {
    notificationId: `notif_${order.id}_shipped`,
    type: 'order_shipped',
    userId: order.customerId,
    priority: 'high',
    data: {
      orderId: order.id,
      trackingNumber: order.trackingNumber,
      carrier: order.carrier,
      estimatedDelivery: order.estimatedDelivery,
      items: order.items.map(i => ({ name: i.name, quantity: i.quantity })),
    },
  });
  // Origin service done - doesn't know about emails, push, etc.
}
 
// Notification Router: Determines channels and dispatches
class NotificationRouter {
  @Subscribe('notification-requests')
  async handleNotification(request: NotificationRequest): Promise<void> {
    // 1. Look up user preferences
    const prefs = await this.userService.getNotificationPreferences(request.userId);
    const user = await this.userService.getById(request.userId);
    
    // 2. Apply template for each channel
    const template = this.templateEngine.getTemplate(request.type);
    
    // 3. Dispatch to enabled channels
    const dispatches: Promise<void>[] = [];
    
    if (prefs.email.enabled && this.shouldSend(prefs.email, request)) {
      dispatches.push(this.publishToChannel('email', {
        ...request,
        to: user.email,
        subject: template.emailSubject(request.data),
        body: template.emailBody(request.data),
      }));
    }
    
    if (prefs.push.enabled && user.pushTokens?.length > 0) {
      for (const token of user.pushTokens) {
        dispatches.push(this.publishToChannel('push', {
          ...request,
          token,
          title: template.pushTitle(request.data),
          body: template.pushBody(request.data),
          deepLink: template.deepLink(request.data),
        }));
      }
    }
    
    if (prefs.sms.enabled && request.priority === 'urgent') {
      dispatches.push(this.publishToChannel('sms', {
        ...request,
        phone: user.phone,
        message: template.smsMessage(request.data),
      }));
    }
    
    await Promise.all(dispatches);
  }
  
  private async publishToChannel(channel: string, payload: any): Promise<void> {
    await pubsub.publish(`notifications.${channel}`, payload);
  }
}
 
// Channel Handler: Email
class EmailNotificationHandler {
  @Subscribe('notifications.email')
  async handleEmail(notification: EmailNotification): Promise<void> {
    await this.sendGrid.send({
      to: notification.to,
      subject: notification.subject,
      html: notification.body,
    });
    
    await this.trackingService.recordDelivery({
      notificationId: notification.notificationId,
      channel: 'email',
      status: 'delivered',
    });
  }
}

System Integration and Event Bridge

Converting Mermaid diagram...

Event Bridge Pattern Benefits

•Protocol translation: Each system uses its native interface; adapters translate to canonical events
•Loose coupling: Systems don't communicate directly; the event bridge mediates all interactions
•Buffering: If a target system is slow or unavailable, events queue up safely
•Transformation: Adapters can enrich, filter, or transform events as needed
•Auditing: Central event bus provides complete visibility into cross-system communication
•Change isolation: Replacing or upgrading a system requires only adapter changes, not rewiring consumers

Canonical Event Model

event-bridge-adapter.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Event Bridge: Salesforce Adapter Example
 
// Canonical customer event (system-agnostic)
interface CustomerUpdatedEvent {
  eventType: 'CUSTOMER_UPDATED';
  source: string;
  customerId: string;
  timestamp: string;
  changes: {
    email?: string;
    phone?: string;
    address?: {
      street: string;
      city: string;
      state: string;
      country: string;
      postalCode: string;
    };
    segment?: 'enterprise' | 'midmarket' | 'smb';
  };
}
 
// Salesforce-specific webhook payload
interface SalesforceAccountUpdate {
  attributes: { type: 'Account'; url: string };
  Id: string;
  Name: string;
  BillingStreet: string;
  BillingCity: string;
  BillingState: string;
  BillingCountry: string;
  BillingPostalCode: string;
  Phone: string;
  Industry: string;
  Type: string; // Enterprise, Channel Partner, etc.
}
 
class SalesforceAdapter {
  // Inbound: Salesforce webhook → Canonical event
  async handleSalesforceWebhook(payload: SalesforceAccountUpdate): Promise<void> {
    const canonicalEvent: CustomerUpdatedEvent = {
      eventType: 'CUSTOMER_UPDATED',
      source: 'salesforce',
      customerId: this.mapSalesforceIdToCanonical(payload.Id),
      timestamp: new Date().toISOString(),
      changes: {
        phone: payload.Phone,
        address: {
          street: payload.BillingStreet,
          city: payload.BillingCity,
          state: payload.BillingState,
          country: payload.BillingCountry,
          postalCode: payload.BillingPostalCode,
        },
        segment: this.mapSalesforceTypeToSegment(payload.Type),
      },
    };
    
    await this.eventBus.publish('customer-events', canonicalEvent);
  }
  
  // Outbound: Canonical event → Salesforce API
  @Subscribe('customer-events', { filter: "source != 'salesforce'" })
  async syncToSalesforce(event: CustomerUpdatedEvent): Promise<void> {
    // Don't echo back events that originated from Salesforce
    const salesforceId = this.mapCanonicalIdToSalesforce(event.customerId);
    
    await this.salesforceClient.updateAccount(salesforceId, {
      Phone: event.changes.phone,
      BillingStreet: event.changes.address?.street,
      BillingCity: event.changes.address?.city,
      // ... map other fields
    });
  }
}

IoT Data Ingestion

Converting Mermaid diagram...

IoT Ingestion Challenges Solved by Pub-Sub:

Scale: Millions of devices, billions of events/day. Pub-sub's horizontal scaling handles the volume.
Buffering: Devices may send bursts; pub-sub smooths traffic for downstream consumers.
Device independence: Devices publish without knowing consumers; new analytics don't require device updates.
Multi-speed consumers: Real-time alerting needs millisecond latency; batch analytics processes hourly. Same stream, different speeds.
Replay for training: ML models train on historical data replayed from the event log.

iot-telemetry-processing.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
// IoT Telemetry Processing Pipeline
 
interface TelemetryEvent {
  deviceId: string;
  deviceType: 'sensor' | 'vehicle' | 'meter' | 'wearable';
  timestamp: string;
  readings: {
    metric: string;
    value: number;
    unit: string;
  }[];
  metadata: {
    firmwareVersion: string;
    batteryLevel?: number;
    signalStrength?: number;
  };
}
 
// Stream Processor: Real-time aggregation and routing
class TelemetryProcessor {
  @Subscribe('telemetry.raw')
  async processTelemetry(event: TelemetryEvent): Promise<void> {
    // Enrich with device metadata
    const device = await this.deviceRegistry.get(event.deviceId);
    
    // Check for anomalies
    for (const reading of event.readings) {
      const threshold = await this.thresholdService.get(device.type, reading.metric);
      
      if (reading.value > threshold.critical) {
        // Publish to alerts topic
        await this.eventBus.publish('alerts.critical', {
          alertId: generateId(),
          deviceId: event.deviceId,
          metric: reading.metric,
          value: reading.value,
          threshold: threshold.critical,
          severity: 'critical',
          timestamp: event.timestamp,
        });
      }
    }
    
    // Aggregate for time-series storage
    const aggregatedReading = {
      deviceId: event.deviceId,
      timestamp: event.timestamp,
      readings: event.readings.reduce((acc, r) => ({
        ...acc,
        [r.metric]: r.value,
      }), {}),
    };
    
    await this.timeSeriesDb.write(aggregatedReading);
    
    // Publish processed event for other consumers
    await this.eventBus.publish('telemetry.processed', {
      ...event,
      deviceMeta: device,
      processedAt: new Date().toISOString(),
    });
  }
}
 
// Anomaly Detection: Subscribes to processed telemetry
class AnomalyDetector {
  @Subscribe('telemetry.processed')
  async detectAnomalies(event: TelemetryEvent): Promise<void> {
    // Run ML model for predictive maintenance
    const prediction = await this.mlModel.predict({
      deviceId: event.deviceId,
      readings: event.readings,
      historicalAvg: await this.getHistoricalAverages(event.deviceId),
    });
    
    if (prediction.maintenanceNeeded && prediction.confidence > 0.85) {
      await this.eventBus.publish('maintenance.predicted', {
        deviceId: event.deviceId,
        predictedFailureDate: prediction.estimatedFailureDate,
        confidence: prediction.confidence,
        recommendedAction: prediction.action,
      });
    }
  }
}

When NOT to Use Pub-Sub

Pub-sub is powerful, but it's not the right tool for every situation. Understanding its limitations helps you avoid misapplying the pattern.

Scenarios Where Pub-Sub May Not Be Ideal

•Request-Response needed: If the caller needs an immediate response to proceed (synchronous workflow), direct API calls may be simpler. Pub-sub is fire-and-forget; faking request-response adds complexity.
•Low message volume: For a handful of messages per hour between two services, the overhead of message broker infrastructure may not be justified. Direct calls work fine.
•Strong transactional requirements: If a saga's compensating transactions must execute synchronously with guaranteed outcomes, carefully orchestrated calls may be clearer than event choreography.
•Ordering MUST be global: If events must be processed in strict global order (not just per-entity order), pub-sub's partitioning makes this hard. Consider a single writer or database-based queue.
•Latency critical (<5ms): Message brokers add latency (typically 10-100ms). For ultra-low-latency needs (trading, gaming), direct communication or shared memory may be required.
•Simple single-consumer queue: If you just need to distribute work to a pool of workers (not fan-out), a simple queue (SQS, RabbitMQ in queue mode) is simpler than pub-sub.

Choosing Communication Patterns
Scenario	Recommended Pattern	Why
Get user profile by ID	Synchronous API	Need immediate response; simple query
Process order asynchronously	Pub-Sub	Multiple consumers; resilience needed
Distribute image resize jobs	Message Queue	Single consumer group; work distribution
Real-time game state updates	WebSocket / direct	Sub-millisecond latency required
Batch ETL processing	Pub-Sub (replay)	Large volume; replay for recovery
Two-phase commit transaction	Orchestrated calls	Atomic guarantee required

Hybrid Architectures

Summary: Pub-Sub Use Cases

We've explored the major production use cases for publish-subscribe messaging. Let's consolidate the key insights:

Key Takeaways

•Event-driven microservices: Pub-sub enables loosely coupled services that communicate through domain events, enabling team autonomy and system resilience.
•Real-time analytics: The same event stream feeds dashboards, data warehouses, and ML pipelines simultaneously, with independent processing speeds.
•CQRS and event sourcing: One event stream projects to many read-optimized views, with replay capability for new projections and debugging.
•Multi-channel notifications: Decouple notification triggers from delivery channels; user preferences determine where notifications route.
•System integration: Event bridges connect disparate systems with canonical events, enabling loose coupling and protocol translation.
•IoT ingestion: Handle massive device telemetry with buffering, multi-speed consumers, and replay for ML training.
•Know when NOT to use it: Request-response needs, ultra-low latency, simple queuing, and strong transactions may call for other patterns.

Module Complete:

Module Complete

5 / 5

Publish-Subscribe Pattern - Page 5 of 5 | OneNoughtOne