Welcome! This is a simple guide to understanding the basic patterns of ZeroMQ (also spelled ØMQ), a high-performance asynchronous messaging library. The animations below will help you visualize how data flows in each pattern.
This is the most straightforward pattern, used for classic client-server communication. It's a strict, lock-step pattern: the client sends a request (REQ) and must wait for the server to send a reply (REP). The client cannot send a new request until it receives a reply.
This pattern is the foundation for most **Remote Procedure Calls (RPCs)** and simple APIs. Think of it like a command-and-control system: a client asks a server to perform an action (e.g., "get user data for ID 123") and waits for a direct response ("here is the data"). It's widely used for service-to-service communication in microservices architectures for tasks that require confirmation.
This pattern is used for one-to-many data distribution. A single publisher (PUB) sends messages to many subscribers (SUB) at once. The publisher has no knowledge of the subscribers. This is a "fire-and-forget" model.
PUB-SUB is ideal for broadcasting real-time information. Common examples include:
This pattern is designed for distributing tasks. A "pusher" (PUSH) sends messages that are load-balanced among a set of "pullers" (PULL). It's great for parallel task distribution.
The Pipeline pattern excels at creating data processing workflows and distributing workloads. It's often called a "workload distribution" pattern.