When Systems Talk Without Knowing Each Other: Pub-Sub

A few years ago, I worked on a customer loyalty platform for a large retailer. Every time a customer made a purchase, multiple systems needed to react. The billing system had to record the transaction. The loyalty engine had to calculate points. The marketing platform needed purchase data to trigger campaigns.

The team considered wiring these systems directly together. The billing service would call the loyalty service. The loyalty service would notify marketing. And so on. But within a few weeks, the design looked like spaghetti. Every new requirement added another direct dependency. One change in one system caused a ripple effect across the others.

We needed a way for systems to talk without being tightly tied together. That’s when the Publisher-Subscriber pattern became the answer.

Pub-Sub in Plain Clothes

The Publisher-Subscriber (Pub-Sub) pattern is simple in concept. A publisher emits events. Subscribers express interest in certain events. An intermediary, usually called a message broker, ensures events are delivered. This decouples producers from consumers. Publishers don’t need to know who is listening. Subscribers don’t need to know where the events originated.

Considerations

Before you get too excited about Pub-Sub, there are some key aspects that architects must weigh. These are not just technical checkboxes, but design choices that affect scalability, flexibility, and the long-term health of the system. These are the points that will either make your implementation shine or cause headaches later.

Scalability

Events can be consumed by many subscribers at once. For architects this means you can design for growth without redesigning producers every time a new consumer is added. Adding a new system does not change the publisher, which protects teams from expensive rewiring and keeps ownership clear.

Flexibility

Business teams can experiment by introducing new event consumers without modifying existing producers. For architects, this opens the door to innovation because you don’t need to plan every downstream integration upfront. The system remains adaptable to new business ideas without increasing coupling.

Resilience

Message brokers often provide buffering and retry, shielding publishers from slow or failing subscribers. From an architect’s perspective, this is crucial because it lets you design for fault isolation. A single bad consumer will not take the whole flow down if the broker is configured correctly.

Trade-offs

No pattern is free of downsides. While Pub-Sub offers many benefits, it also introduces challenges that can trip up even experienced teams. These trade-offs are worth thinking about early, because fixing them later often costs more than you expect.

Visibility

When many systems subscribe to events, it becomes harder to trace the full impact of one message. For architects this means troubleshooting becomes a cross-team exercise. You need solid observability, correlation IDs, and tracing strategies to know where an event went and what it triggered. Without these, the system becomes a black box.

Ordering and Delivery Semantics

Some brokers provide at-least-once delivery, others exactly-once, and ordering guarantees vary. Architects must design accordingly, because the business impact of duplicate or out-of-order messages can be severe. Think of financial transactions or inventory updates: one extra or misordered event can cause inconsistencies that ripple across the organization.

Schema Evolution

Changes in event payloads must be carefully managed to avoid breaking subscribers. Contracts are critical, and architects need to enforce governance around event versions and backward compatibility. If neglected, even a small change in an event field can silently break consumers in production, creating costly outages.

When to Reach for the Pub-Sub Hammer

Architects need to judge where the added complexity of an event-driven approach truly pays off. Pub-Sub shines when you need to decouple systems, scale to many consumers, and prepare for unknown future needs. It is less suitable when interactions are simple and point-to-point is enough. This is the decision point where architectural foresight makes or breaks the solution. Architects should consider Pub-Sub:

• When multiple downstream systems need the same information.
• When you want to avoid point-to-point integrations.
• When agility is key and new consumers may appear later.

Architects often jump too quickly into tool selection, but this step deserves careful thought. Implementation is not just about picking a broker and wiring some events. It is about defining contracts, planning for observability, and making choices that will impact scalability and maintainability for years.

Pick your poison broker

For architects, the decision here is critical: each broker comes with its own trade-offs in cost, ecosystem support, performance guarantees, and operational complexity. The choice should reflect not just today’s throughput but also how easily the system can evolve in five years.

Broker	Key Strength
Kafka	High-throughput and replayability
RabbitMQ	Flexible routing
Azure Event Grid	Cloud-native integration
AWS SNS	Cloud-native integration

Don’t wing your events

Use schema registries or versioned event formats. For example, tools like Confluent Schema Registry or Azure Schema Registry help maintain strong contracts, and common formats such as Avro, Protobuf, or JSON Schema enforce consistency across producers and consumers. Make events business-oriented, like CustomerPurchased rather than technical. For architects this means defining contracts that will live for years and may be consumed by teams you have never met. Loose event design today can create governance nightmares tomorrow.

Avro example:

{
  "type": "record",
  "name": "CustomerPurchased",
  "fields": [
    {"name": "customerId", "type": "string"},
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"}
  ]
}

Protobuf example:

syntax = "proto3";

message CustomerPurchased {
  string customerId = 1;
  string orderId = 2;
  double amount = 3;
}

JSON Schema Example:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "CustomerPurchased",
  "type": "object",
  "properties": {
    "customerId": {"type": "string"},
    "orderId": {"type": "string"},
    "amount": {"type": "number"}
  },
  "required": ["customerId", "orderId", "amount"]
}

Get eyes on your events

Implement tracing across published events. Without it, debugging becomes guesswork. Architects must consider observability from day one: distributed tracing, correlation IDs, dashboards, and alerting are not luxuries but core design elements. Without them, you trade architectural elegance for operational blindness. Practical tools to get started include OpenTelemetry for distributed tracing, Jaeger or Zipkin for visualization, and cloud-native options like AWS X-Ray or Azure Monitor. Begin with instrumenting one critical flow end-to-end, then expand coverage gradually to build confidence and operational insight.

Expect failure, design for it

Use dead-letter queues for unprocessable events. Design idempotent subscribers. For architects, resilience must be baked in at the pattern level: consumers will fail, events will arrive twice, and payloads will sometimes be malformed. Building for failure makes the difference between graceful degradation and a complete outage.

Pub-Sub as a Strategic Tool for Architects

The Publisher-Subscriber pattern enables systems to communicate without knowing each other directly, bringing scalability, decoupling, and agility into the architecture. Yet those benefits only materialize when architects treat event design, monitoring, and governance as their most important responsibilities. Pub-Sub should be seen as a lever for long-term independence and growth. It delivers scalability without constant rewiring, flexibility to add new consumers quickly, and resilience against failures. But it also comes with trade-offs that demand careful handling of observability, contract management, and delivery semantics.

If you are facing scenarios where multiple consumers must react to the same events, resist the temptation to wire systems point-to-point. Instead, adopt an event-driven mindset, define strong event contracts, and invest early in observability. Use Pub-Sub not just to fix integration pain today, but to prepare your architecture for the changes and opportunities of tomorrow.