Skip to content
←Communication & Integration

// Communication & Integration · 06

Publish / Subscribe

Publisherleads toTopicleads toEvery subscriber

Announce it once. Everyone who cares gets their own copy.

How it fits together

Publish / Subscribe structureOrders servicepublishes OrderPlacedOrderPlaced topicone subscription eachevery one gets a copyBillingown subscriptionShippingown subscriptionAnalyticsown subscription1 publish2 copy2 copy2 copy
publishes / notifies· numbered steps replay in order
  • Orders service publishes / notifies OrderPlaced topic (1 publish)
  • OrderPlaced topic publishes / notifies Billing (2 copy)
  • OrderPlaced topic publishes / notifies Shipping (2 copy)
  • OrderPlaced topic publishes / notifies Analytics (2 copy)

Spot it

  • One service calls five others after each order
  • Adding a consumer means changing the producer
  • Teams wait on each other to react to an event

It costs

The producer no longer knows who reacts, so the flow is harder to trace and debug.

In code

public sealed record OrderPlacedV1(    Guid OrderId,    string CustomerId,    decimal Total,    DateTimeOffset PlacedAt);​public sealed class OrderEvents(ITopicPublisher topic){    public Task PublishPlacedAsync(Order order, CancellationToken ct)    {        var data = new OrderPlacedV1(order.Id, order.CustomerId, order.Total, order.PlacedAt);        var envelope = new EventEnvelope<OrderPlacedV1>(            EventId: Guid.NewGuid(),            Type: "orders.order-placed",            Version: 1,            OccurredAt: DateTimeOffset.UtcNow,            Data: data);​        return topic.PublishAsync("orders", envelope, ct);    }}
Go deeperThe full explanation and what to ask for · 1 min readExpand

The publisher sends an event to a topic without knowing who listens. Each subscription gets its own copy and its own backlog, so a slow or failing subscriber does not hold up the others, and new subscribers can be added without touching the publisher.

The classic mistake is treating events as remote commands, naming a specific receiver or waiting for a reply, which brings the coupling back. Another is breaking the event contract: every subscriber depends on its shape, so evolve it additively and version it.

Within one subscription, consumers still compete as on a queue. Pub/sub is the transport of event-driven architecture; pair it with a transactional outbox so events match committed data, and expect duplicates and reordering.

Ask for it

  • topic
  • subscription
  • fan-out
  • subscription filter
  • event contract
  • durable subscription

Publish OrderPlaced to a topic with one subscription each for Billing, Shipping and Analytics, filters where needed and a dead-letter queue per subscription. Version the event and only add fields. Use your broker topic feature (Azure Service Bus, SNS to SQS, Kafka consumer groups).

Connects to