Skip to main content

Communication Patterns

Learning Objectives​

By the end of this lesson, you will be able to:

  • Recognize several common communication patterns in distributed systems and protocols.
  • Identify when to use request–response, publish–subscribe, and message‑queue‑style patterns.
  • Sketch how these patterns fit into Flow‑style protocols (e.g., governance events, ML‑driven alerts, or on‑ramp flows).
  • Decide, at a high level, which pattern is right for a given Flow‑style interaction.

Introduction​

So far you have learned:

  • the difference between protocol and application,
  • and how to model behavior over time with state machines.

Now it is time to look at how messages move between components:

  • who sends what,
  • who receives what,
  • and when.

These are communication patterns. They are not protocols by themselves, but they shape how protocols are structured [web:372][web:380].

In Flow‑style systems, choosing the right pattern affects:

  • responsiveness,
  • coupling,
  • and scalability.

What Are Communication Patterns?​

A communication pattern is a reusable way that components exchange messages in a system [web:372][web:380].

Patterns impose structure on questions like:

  • Is the sender blocked while waiting for a reply?
  • Does the sender know its exact receiver(s)?
  • Is communication synchronous or asynchronous?

By picking a pattern up front, you avoid inventing a new ad‑hoc scheme for every interaction.

Key Communication Patterns​

1. Request–Response​

Request–response (also called pull) is the most familiar pattern [web:378][web:384]:

  • A client sends a request to a server.
  • The server processes the request and sends back a response.
  • The client usually waits until it receives the response.

Examples:

  • HTTP requests and responses.
  • API calls to a model‑serving endpoint.
  • queries to a governance‑state or learner‑profile service.

When to use request–response:

  • When you need immediate answers and it is okay to block while waiting.
  • When interactions are point‑to‑point (one sender talks to one known receiver).

In Flow‑style systems, this is natural for:

  • dashboards asking for updated state,
  • or for on‑ramp forms that must immediately validate.

2. Publish–Subscribe (Pub/Sub)​

Publish–subscribe (pub/sub) is a pattern where:

  • Publishers send messages to channels or topics without knowing who will receive them.
  • Subscribers express interest in certain topics and receive messages that match [web:371][web:377].

No one component has to know all the others; they just know the topic semantics.

Key properties:

  • Decoupled: publishers and subscribers do not need to know each other.
  • Asynchronous: the sender does not wait for everyone to receive the message.
  • Many‑to‑many: one event can reach many listeners.

Examples:

  • Event‑driven systems (e.g., “proposal‑created”, “vote‑received”, “reward‑processed”).
  • Notification systems (e.g., “new learning path available”, “governance‑event scheduled”).

When to use pub/sub in Flow‑style contexts:

  • You want event‑driven workflows (e.g., governance‑events, ML‑driven alerts).
  • You want to avoid hard‑coded dependencies between components (e.g., dashboard, analytics, rewards, and governance services).

3. Message Queues (Point‑to‑Point)​

Message queues (also called point‑to‑point or queue‑style) are:

  • A producer sends a message to a queue.
  • A consumer (or set of consumers) reads and processes messages from that queue, often in order [web:372][web:380].

Unlike pub/sub, a queue usually:

  • targets one or a small group of consumers,
  • may ensure at‑least‑once or exactly‑once delivery.

Key properties:

  • Decoupled in time: the producer can send messages even if the consumer is offline.
  • Ordered and buffered: the queue can smooth out bursts of work.

Examples:

  • Task queues (e.g., “process this governance‑proposal”, “compute this reward‑batch”).
  • Background jobs (e.g., re‑score learners, aggregate activity logs).

When to use message queues:

  • You have asynchronous work that should not block the user.
  • You want to balance load over time (e.g., ML‑based scoring, bulk computations).

4. Other Common Patterns (High‑Level View)​

Several other patterns appear in protocol and distributed‑system design [web:372][web:380]:

  • Event‑driven: components react to events from other parts of the system (often layered on top of pub/sub or queues).
  • Broadcast/multicast: one sender sends to many receivers simultaneously (sometimes used in IoT or real‑time dashboards).
  • Push / pull streaming: systems that continuously stream data (e.g., WebSockets, Kafka‑style topics).

You don’t need to dive deep into all of these now; the key is to recognize them when you see them and know that they are patterns, not random ad‑hoc designs.

Choosing a Pattern for Your Flow‑Style Protocol​

To decide which communication pattern to use, ask:

1. Do you need an immediate answer?​

  • Yes → lean toward request–response.
  • No → lean toward pub/sub or message queues.

2. Do you know your receivers?​

  • Yes (specific, known services) → request–response or message queues.
  • No (many unknown services may care) → pub/sub.

3. Do you want decoupling and async?​

  • Yes → pub/sub or message queues.
  • No (simple client–server interaction) → request–response.

In Flow‑style thinking, a typical setup combines:

  • request–response for user‑facing APIs (e.g., dashboard queries).
  • pub/sub (or event streams) for protocol‑level events (e.g., governance‑state changes, learner‑activity events).
  • message queues for background work (e.g., re‑scoring, batch processing).

This allows you to keep core protocols simple and let applications opt in to what they care about.

Practical Exercises​

Exercise 1: Identify Patterns in Existing Systems​

Pick two real‑world systems you know (e.g., a web app, a learning platform, or a governance‑tool):

  • For each, identify at least one request–response interaction.
  • Identify at least one pub/sub or event‑driven interaction (even if you only infer it).
  • Write a short note explaining why each pattern fits that use‑case.

This trains you to see patterns instead of “just HTTP.”

Exercise 2: Sketch a Flow‑Style Event‑Driven Flow​

Design a small Flow‑style workflow (e.g., governance‑proposal approval):

  • Decide which parts should use request–response (e.g., user submits a proposal).
  • Decide which parts should use pub/sub (e.g., “proposal‑submitted” event that triggers notifications, analytics, and governance‑dashboard updates).
  • Decide which parts should use message queues (e.g., async scoring or reward‑calculation).

Sketch this as a simple diagram or list of steps annotated with patterns.

Exercise 3: Refactor a Design​

Take a design you previously wrote as a plain request–response API:

  • Imagine replacing some of its synchronous calls with events and queues.
  • Write a short note describing what would change and how this affects coupling and observability.

This helps you move from “everything is an immediate API call” to pattern‑aware design.

Self‑Assessment​

Rate yourself from 1 to 5:

  • I can explain request–response, pub/sub, and message queues at a high level.
  • I can say when each pattern is appropriate for a given interaction.
  • I can sketch which pattern to use for Flow‑style use‑cases like governance‑events or ML‑driven alerts.
  • I can see how communication patterns sit under protocol design.

Action item: write a short note in your lab repo describing one Flow‑style interaction you reframed using a better communication pattern and why that improved the design.

Video​

Next Steps​

  • Read 04-protocol-specification.md next to learn how to write text‑plus‑diagram spec for protocols that use these communication patterns.
  • Treat communication patterns as first‑class design choices, not implementation details.
  • When you design a protocol, start by asking: “What pattern will we use for this interaction?”

This lesson gives Flow Initiative trainees a beginner‑level understanding of communication patterns in distributed systems and protocols, focusing on request–response, publish–subscribe (pub/sub), and message‑queue styles, and how to choose the right pattern for Flow‑style governance‑event, ML‑driven, and on‑ramp flows.