Subscription

A Danube subscription is a named configuration rule that determines how messages are delivered to consumers. It is a lease on a topic established by a group of consumers.

Danube permits multiple producers and subscribers to the same topic. Subscription types can be combined to build queuing (point-to-point) or fan-out (broadcast) messaging patterns — see examples below. For delivery semantics, see Dispatch Strategies.

Exclusive

The Exclusive type is a subscription type that only allows a single consumer to attach to the subscription. If multiple consumers subscribe to a topic using the same subscription, an error occurs. This consumer has exclusive access to all messages published to the topic or partition.

Exclusive subscription on Non-Partitioned Topic

• Consumer: Only one consumer can be attached to the topic with an Exclusive subscription.
• Message Handling: The single consumer handles all messages from the topic, receiving every message published to that topic.

Exclusive subscription on Partitioned Topic (Multiple Partitions)

• Consumer: One consumer is allowed to connect to the subscription across all partitions of the partitioned topic.
• Message Handling : This single consumer processes messages from all partitions of the partitioned topic. If a topic is partitioned into multiple partitions, the exclusive consumer handles messages from every partition.

Shared

In Danube, the Shared subscription type allows multiple consumers to attach to the same subscription. Messages are delivered in a round-robin distribution across consumers, and any given message is delivered to only one consumer.

Shared subscription on Non-Partitioned Topic

• Consumers: Multiple consumers can subscribe to the same topic.
• Message Handling: Messages are distributed among all consumers in a round-robin fashion.

Shared subscription on Partitioned Topic (Multiple Partitions)

• Consumers: Multiple consumers can subscribe to the partitioned topic.
• Message Handling: Messages are distributed across all partitions, and then among consumers in a round-robin fashion. Each message from any partition is delivered to only one consumer.

Failover

The Failover subscription type allows multiple consumers to attach to the same subscription, with one active consumer at a time. If the active consumer disconnects or becomes unhealthy, another consumer automatically takes over. This preserves ordering and minimizes downtime.

Failover subscription on Non-Partitioned Topic

• Consumers: One active consumer processes all messages; additional consumers are in standby.
• Message Handling: If the active consumer fails, a standby consumer takes over and continues from the last acknowledged position.

Failover subscription on Partitioned Topic (Multiple Partitions)

• Consumers: One active consumer per partition; other consumers remain on standby for each partition.
• Message Handling: Failover occurs independently per partition, ensuring continuity and ordering within each partition.

Messaging Patterns

Subscription types map directly to common messaging patterns:

Queuing (Point-to-Point)

One message is delivered to exactly one consumer in a group. Use a Shared subscription with the same name across all workers:

• Topic: /default/orders
• Subscription: orders-workers (type Shared)
• Run N consumers with the same subscription name. Messages are load-balanced round-robin across them.

Fan-Out (Broadcast)

Every downstream service receives every message. Create a separate subscription per service, typically using Exclusive or Failover for HA:

• Topic: /default/events
• Subscriptions: billing (Exclusive), analytics (Exclusive), monitoring (Failover)
• Each subscription receives the full event stream independently.

Choosing a Dispatch Mode

Both patterns work with either dispatch mode:

• Non-Reliable — lowest latency, best-effort delivery, no persistence.
• Reliable — at-least-once delivery with WAL + Cloud persistence and replay.

See Dispatch Strategies for details.