Differences in Durable and Non durable subscriptions of a topic endpoint

Hi @rdesoju,
Let's approach this problem by taking a quick step back. In order to really achieve the benefits that an event-driven architecture promises we need to make sure we're able to decouple our publishers from our subscribers. The way PubSub+ Event Brokers work allow you to easily do this. As a publisher you publish your messages/events to topic(s). The topic an event is published to is really just a label in the message header (it's not an endpoint!). This label will then be used by the Event Broker to decide which subscribers to route the event to. So do not think of a topic on the publishing side as where you are publishing to but more so think of it as a way to provide metadata that describes what you are publishing. This what is useful for your subscribers to filter the events that they want to receive. A few examples here:

So now that we have events being published to a topic that describes what we are publishing the event broker can now use that topic metadata to decide which application(s) receive those events. This includes whether an event is sent to 0, 1 or fanned out to many subscribers (like your use case). In order to know where to route the events the subscribers must tell the event broker what events they are interested in. This is done by specifying topic subscriptions and there are a few different ways to do this depending on your requirements. The two most common options that I see are as follows:

1). It's okay if I miss messages during network outages or if my app is down. Then my app is fine with consuming from the non-persistent event stream and will make my topic subscriptions directly
2). It's NOT okay if I miss messages when issues occur. Then my app needs to consume from the persistent event stream and will bind to a durable endpoint to consume events. The durable endpoint exists on the broker, is configured with topic subscriptions to attract events based on their topic metadata, and will persist events if my apps goes down or offline. So each endpoint captures

Hopefully that background information around the decoupling of publishers from subscribers helps with the answers below...
So let me answer your two questions:

1). This is indeed expected! To quote from our docs:

For an exclusive topic endpoint, only one client can bind and receive messages; if other clients attempt to bind, they will be rejected. An exclusive durable topic endpoint always delivers messages in the order they are received. For non-exclusive durable topic endpoints, multiple consumers can bind and each is serviced in round‑robin fashion.

2). If you're using Durable Subscribers then I assume your subscribers fall into the category of number 2 above. You don't want to lose messages when your app(s) go offline. In order to do this you need a durable endpoint for each copy of the event stream that will be delivered to your apps so the broker can individually manage the events after fan out. As @amackenzie suggested the most common way to do this is to create a queue endpoint for each app. A queue endpoint allows you to have multiple topic subscriptions on one endpoint and also the ability to have multiple instances of an application for round-robin (w/ a non-exclusive queue) or high availability primary/secondary/tertiary (w/ an exclusive queue).

Hi @rdesoju,
1. Correct. You need a durable endpoint for each copy of the event stream that you want delivered. I highly recommend reading about how Solace Event Streaming works on this docs page. It's great information and I personally revisit it a lot to as a refresher too https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm
2. The reason this is happening is because the persistent subscribers are actually binding to the same durable endpoint which is receiving one copy of the persistent event-stream. And then from that durable endpoint (which is non-exclusive) the messages are being shared across the apps bound to it. The opposite is true for your non-durable subscriptions. They are not using durable endpoints and are each getting their own copy of the event stream.