Subscriptions
A FlowMQ Subscription provides a classic publish/subscribe (pub/sub) messaging model designed for real-time, fanout message delivery. When a message is published to a topic, a Subscription will immediately broadcast it to all of its currently active consumers.
Unlike Queues and Streams, Subscriptions are typically non-durable. If a consumer is not connected to the subscription when the message is delivered, it will miss the message. This makes Subscriptions perfect for ephemeral, "in-the-moment" data where low latency is critical and historical replay is not needed.
Common use cases include live chat applications, real-time notifications, financial data tickers, and collaborative whiteboarding tools.
The Fanout Model
The core of a Subscription is the fanout delivery model. Every consumer attached to the same subscription receives a copy of each message. This is in direct contrast to a Queue, where consumers compete for messages.
Key behaviors of this model include:
- Broadcast Delivery: Every active consumer on the subscription gets a copy of the message.
- Non-Durable: Messages are not stored for disconnected clients. Delivery is real-time and "fire-and-forget."
- No Acknowledgments: Because messages are not persisted for redelivery, consumers do not acknowledge them. This simplifies the consumer logic and reduces network overhead.
Binding to Topics
Like Queues and Streams, a Subscription is defined by its name and a binding to a topic filter (e.g., sports.scores.nfl.#). When a producer publishes a message to a topic that matches this filter, the broker immediately fans it out to all active consumers on that subscription.
This continues FlowMQ's core design principle of decoupling producers from consumers, allowing you to add or remove real-time subscribers without ever touching the publisher's code.
When to Use a Subscription vs. a Queue or Stream
Choosing the right tool is critical for building an efficient architecture.
| Use Case | Best Choice | Why? |
|---|---|---|
| Distributing tasks to workers | Queue | Ensures each task is processed by only one worker, with guaranteed delivery. |
| Broadcasting events for replay | Stream | Provides a persistent, replayable log for multiple independent consumer groups. |
| Real-time notifications | Subscription | Delivers messages instantly to all active clients with low latency. |
| Load balancing services | Queue | Automatically spreads requests across a pool of service instances. |
| Event Sourcing | Stream | The immutable log is the perfect foundation for a system of record. |
| Live chat messages | Subscription | Messages are ephemeral and need to be broadcast to all users in a room. |
| Asynchronous API requests | Queue | Reliably offloads work to a background service for processing. |
In summary:
- Use a Subscription for low-latency, real-time fanout to active clients.
- Use a Queue for reliable, one-to-one work distribution.
- Use a Stream for one-to-many, durable, and replayable event history.