Scalable .NET Pub/Sub Messaging using NCache

Recorded webinar
By Ron Hussain and Edward Bator

In this webinar you will learn how you can use powerful Pub/Sub messaging for high traffic .NET applications and overcome performance bottlenecks. NCache is a scalable distributed cache for .NET that provides a rich set of Pub/Sub Messaging features.

One of our senior solution architects will walk you through all the Pub/Sub features and their use cases, and show you how can incorporate them in your .NET application.

This webinar covers:

  • Introduction to Pub/Sub messaging in general
  • Understanding NCache Pub/Sub features
  • Setting up Pub/Sub in NCache
  • Hands-on using Pub/Sub in your .NET apps
  • Demo of Pub/Sub messaging through NCache
  • NCache high availability and scalability for Pub/Sub

Today's topic is going to be around messaging within .NET applications and we'll be using NCache as an example product. Main focus is going to be Pub/Sub messaging. The publisher subscriber model. Why it is important? Where exactly you use it and why NCache is a better fit in comparison to other options that you see for your .NET and .NET core applications? So, we have a lot to cover. Let's quickly get started with this and guys if there are any questions as Eddie has suggested use the question answer tab and ask as many questions as you need to. So, let's quickly get started.

What is Pub/Sub?

First few slides are focused on the intro part. What is Pub/Sub? I'm pretty sure everybody knows but just for the sake of completeness, I'm going to go over the Pub/Sub messaging paradigm.

So, it's a publisher subscriber model. It has primarily three components. We have publisher, which sends messages, broadcasts those messages to the communication channel. Then we have subscribers, which could be another application, which is receiving those messages and then we have a communication, bus a broker, a service, a process within a publisher and subscriber intermediate component which helps relay those messages from publishers to the subscribers. In some cases, you can store messages, you can process messages. This could be time base, this could be based on your recipients.

How Pub/Sub Works?

So, there are different options that you can tune when you plan on using it. But, in general there are some guidelines, some rules which are common to typical Pub/Sub messaging platform. It's loosely coupled. Publisher and subscribers, they can work independently without having any dependency on one another. They can be completely unaware of each other as well and the system should work without issues. The whole idea is that, publisher simply sends messages to the communication channel and then communication channel relays those messages and subscribers receive those messages. Publisher doesn't need to know about identity or information about subscriber applications and similarly subscribers don't need to do know what publisher information is. They can just deal with the messages, that's the main point of interest and the whole idea is that each component works independently. Publishers don't have any dependency on communication channel or on the subscribers and vice versa as well.

Most of the publisher subscriber models, Pub/Sub models allow you to have separation of concerns, where you can have topics or channels or streams. These are used to separate out messages. So, messages of similar nature which serve a simple single purpose, they can be put in a specific topic and you can have multiple topics, multiple streams, multiple channels, within a Pub/Sub messaging paradigm and you can receive those messages. Publishers connect to topics and then this transmits those messages to a certain topic and then subscribers can also connect to a topic within the communication channel and then receive those messages and it works absolutely fine, using this topic-based approach.

Here is a diagram, which highlights the architectural details.


We have a topic, this is communication channel, this is the publisher application that we have subscriber applications. There could be multiple publishers. Similarly, there could be multiple subscribers and then within communication channel you can have multiple topics as well. For example, you can have one topic which is dealing with order processing information. There could be another topic which is dealing with customer information and so on so forth. So, based on the purpose of the message, based on the type of the message, this is the load requirements, you can distribute messages into topics and then this Subscriber is connected to Topic A, where as Subscriber 2 is connected to Topic A as well as to B and then Subscriber 3 is only connected to Topic B. So, publisher sends these messages and those subscribers which are connected to the respective topics, they receive those messages without issues.

Common Use Cases of Pub/Sub

Alright, so, moving on next. What are the common use cases of Pub/Sub? It's been in the market for quite some time, this whole Pub/Sub messaging paradigm and it's been used in a lot of high-traffic applications as well. It has a lot of traction.

So, we have backend systems, primarily, which can benefit from Pub/Sub messaging which deal with async data processing. It could be some workflows, some background tasks, some procedures that you need, some calculations that you're doing. So, back-end systems primarily use this messaging platform.

Chat applications, this could be gaming industry, which may be dealing with millions of users, millions of messages, being transmitted for users. For example, one of our customers was using Pub/Sub for from information sharing when there were different tournaments in their gaming site. So, they were sharing a lot of tournaments related information between users.

Financial industry, E-commerce, bookings any, anything which is public facing and they need to do some backend order processing, some booking processing or in general provide some interaction between different components of application.

Automation and manufacturing plants. But, typically, it could be the most important use case, would be a technical use case, would be the microservices use case. Where we have different microservices, which are representing a big application but these components server single independent purpose. It's very difficult to implement the communication layer for those microservices. You would have to have separate communication channel acting again as a microservice, which has ability to no other microservices as well and that's the whole idea where you would like to have a microservices layer which is independent, the microservice instances are independent from one another. One instance is doing a single purpose and it's not dependent on another and vice versa. So, for those microservice applications, where we have microservices within the application, implementing communication channel is very difficult and it complicates and it has a lot of dependency in it, slows things down as well. So, it makes a lot of sense to use a Pub/Sub messaging platform, where communication channel is managed by the platform itself and then microservices act as publishers and subscribers and then they share information between one another. So, that should help relieve the load as well as the architectural issues that you typically see with Pub/Sub, the microservices platforms applications using communication channel of their own. They should use Pub/Sub to help relieve that.

The Problem: Scalability Issues with Pub/Sub Platforms

There are many Pub/Sub platforms, but typically there are bottlenecks and that's what we're going to cover next. We have typical traditional messaging platforms. They are very good in terms of the architectural side of things. You send a message, that message is going to be transmitted to all the subscribers, everything works fine. But typically, this works very well under low load. When you have less user, load as well as less number of requests or less number of messages being transmitted back and forth to your application. As far as load, when application load grows, for example, there are a lot of users, a lot of processing happening and then there are a lot of messaging load from publishers to the subscribers, typically, we've seen that our traditional messaging platform, such as database, they become a bottleneck. Here is a diagram which illustrates this.

The Scalability Bottleneck

We have publisher applications, subscriber. This could be web application, some .NET or .NET Core backend. Some workflows. It could be any sort of .NET or .NET Core application or even Java application, connected to a traditional massing platform such as database or messaging queue. First of all, these are not as fast as in-memory store, right. So, that's something which you need to work through. But the main issue is that when your messaging load grows, when you have a lot of users, things start to slow down because your messaging load can choke down the platform itself because it's a single source. It does not have ability to add more and more servers to help accommodate the increased load that your applications are putting.

So, that's the main issue and what would be the end user impact? For example, a message did not get relayed in timely manner, it took a lot of time and that contributed towards latency on the application side. For example, the end user was waiting for a processing to be done and that processing was dependent on a Pub/Sub model platform and platform was slow. So, that would in turn impact the end user request as well and you will lose business if there are let's say, a factor of millisecond or a few seconds delay, then that can impact the end user and that will in turn impact your business as well and that's very difficult to manage, because there's no way, you can change anything inside application architecture to help resolve that problem. There is a problem, which is outside the application architecture with the database layer, right. So, how to tackle that particular scenario?

The Solution: In-Memory Distributed Cache

Solution is very simple, that you use an in-memory Pub/Sub messaging platform which is distributed in nature, such as NCache. It's super-fast, that's what makes it apart from traditional messaging platforms. It may have less features, I would admit that. Since, NCache’s main focus is to have object caching, data caching, session caching, is there for processing of data and storage and performance improvement. Pub/Sub is one of the features. There are products such as messaging queues, for example, Java messaging service, MSM queue, those are more elaborate. But what makes NCache apart from these products is that NCache is the in-memory. So, it's super-fast to start-up.


So, if you have let's say, five users and you have less number of messaging load, those users are going to see super fast experience in comparison to traditional messaging platforms. So, it's in-memory. So, that's a big plus and then we have multiple servers hosting that messaging platform. You can see a team server joined together into a logical capacity which formulates the messing platform and it has a Pub/Sub mechanism implemented on top of it, right. So, your publisher applications can connect to this cache and within the cache you can have separate topics. I'll show you how this works, down the line and then subscribers, which can also be publishers by the way, they are also connected to the same communication channel which is offered by NCache as in the form of distribute cache and then that communication channel offers all the communication related information to these publisher and subscriber. This can relay messages and this could have all these different sorts of explorations, some different sort of persistence and different features that I'll highlight down the line.

Nice thing about this platform is that you can add as many servers as you need to and you don't have to worry about your platform being a scalability bottleneck as seen right here. So, it's not a scalability bottleneck anymore. You can add more servers on the fly and from two to three servers you increase by a factor right and from three to four servers, you almost double the capacity of how many requests you can handle, how many messages you can handle per second and without compromising on the performance, it would give you linear scalability improvements for your message delivery and that would help a lot on the application side. End users would benefit a lot, where they would see faster response time, low latency and high throughput for your application and users.

Any questions so far? This covers why you should consider using NCache in comparison to traditional and what are the issues with traditional Pub/Sub messaging platform. Any questions so far? Next few slides are focused on architectural details of NCache Pub/Sub messaging and then we'll talk about different features, which are being offered as part of this. Hi Ron, we have a question. What are the monitoring options available? OK, I think it's in regards to NCache, yes, that's another plus which I have a segment towards the end lined up just for this. But I think, it would be very good if I wait till that portion and give you the hands-on demo of the product and as part of that I shall also show you the monitoring capabilities. So, I'll revisit this question, once I am at that portion. I hope that's ok.

NCache Pub/Sub Messaging

Alright, NCache Pub/Sub messaging. It's very similar to what you've seen right here. It's a traditional Pub/Sub messaging platform. Here is the architecture breakdown. We have messaging channel offered by NCache and we have team of servers right here and within that messaging channel we have Topic 1, Topic 2 and then we have publisher which could be any .NET, .NET Core application and then we have subscribers which are again any .NET or .NET Core, even Java application, which is connected to it.


A dedicated cache can be formulated for this and then message is something which is relayed from the communication channel using the typical Pub/Sub mechanism, where a message is sent from publisher to subscribers. Here is a simple code snippet.

Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
Cache cache = NCache.InitializeCache("PubSubCache");

ITopic orderTopic = cache.MessagingService.CreateTopic("orderTopic");

Message orderMessage = new Message(payload);

// Publish message to all registered subscribers
// Register delivery failure notification

orderTopic.Publish(orderMessage, DeliveryOption.All, true);

Just to get you an idea that you construct your payload, which is the object of interest, initialize the cache which means get connected to it, name it, you can create a cache cluster with different servers, then you create a topic or get connected to an existing topic. Topic is a channel, a separate medium for similar messages and then you construct a message and then publish it and that's it. That's how simple it is for the basic use case.

On the subscriber side, again you need to get connected to a topic or create a new topic and then become a subscriber using create subscription method and then there's a call-back which gets invoked each time a message is received and this is an asynchronous call-back.

Cache cache = NCache.InitializeCache("PubSubCache");

ITopic productTopic = cache.MessagingService.GetTopic(topicName);

ITopicSubscription prodSubscriber = prodTopic.CreateSubscription(MessageReceived);

private void MessageReceived(object sender, MessageEventArgs args)
 // Perform operations

A hands-on Demo

I should quickly give you the demo of the product and then I think, it would be a lot more easier to understand once we have done the demo. I would go ahead and as part of this, I would also answer the monitoring options as well. All right, so, I would quickly go ahead and show you the NCache manager tool, which comes installed with it.

Create a Cache

I'm going to create a new cache.


Let’s name it, PubSubCache and I'm going to append Windows Win at the end. All caches need to be named. You can name your Pub/Sub cache, something that is meaningful to your application. You can create a cache, NCache allows you to create a cache on Windows environment, Windows servers, as well as on Linux servers and we also have Windows mono release as well, which is also available. So, with Linux you need to use .NET Core and on Windows you can use .NET as well as .NET Core releases of NCache. So, I'm going to go ahead with Windows servers. Choose partition replica cache because I want to have multiple servers contributing towards request handling capacity.


So, Partitioned and Partitioned Replica are very good options. Partitioned Cache allows you to partition data on multiple servers, whereas Partitioned Replica is similar to Partitioned, but it also has backups as well. So, it's entirely up to you. If you want to have the messages are important in nature, if from one server goes down, you don't want to lose the messages which are still in the communication channel, then you can use Partitioned Replica otherwise, Partitioned Cache is more perform eccentric.

There are two other topologies but those are for smaller configurations and our NCache architecture webinar covers all the details around these topologies very effectively. So, I would recommend that you visit those, review that webinar if you need to know more about these topologies. I will keep everything simple. Choose Async as a replication option.


That is between active partition and the backup on another server and here I specify the team of servers which are going to host my cache cluster. I can have two to start off and I can add more servers at any point in time as discussed earlier. This is a TCP port by the way. Every communication between NCache is driven through TCP/IP and size is something which is the size per server. So, based on the messaging load, based on the data load, we recommend that you configure a relevant size for your applications. I'll keep everything simple. Start this cache in auto start, so that each time server gets rebooted cache automatically gets started and that's it.


That's how simple it is to configure this cache and next, I'll show you how to run the application, but I would need one more step before we move on to that. It's starting as well, so it's taking slightly, alright, there you go.

Monitor Statistics

So, there was a question around monitoring options, I think I should tackle that right now. I'm going to add my box as a client, from where I'm going to run the publisher and subscriber application. These can run from any server as well, which has access to this cache. I've added my box as a client so, that's essentially the client box. I can add another box and from that I can also run applications. You notice that there are some statistic window options which are available in the manager tool, but for Pub/Sub what I would initially do, I would launch NCache monitor tool and then I would also show you some of the counters which are available specifically for Pub/Sub.


For example, this is my Pub/Sub dash. I will go ahead and this is NCache monitor tool which comes install with NCache. I think I need, 1 by 3 is good. Alright, so, first of all, if you notice we have topic statistics. Then we have some messages published per second let's say, message count and then we have message expire per second. I think, that's a good one. You can add more as well by the way. There are many here and then there are PerfMon counters which are also available. Let me enable those as well and then I will run an application to show you how this works. I just need to show you the counters and our monitor tool is also using PerfMon counters. So, what you're seeing right here are also available in monitor and vice versa as well. Alright, so, we're all set up. So, we have some counters here as well. For example, message count, deliver per second expired. So, you can see the numerical view, the numeric view and then we also have graphic view in the monitor as well.

Run a Publisher

Now, I would run an application which comes install with it but I've tweaked it a little bit, so that I can publish as many messages as I need to. So, this is App config one for publisher and then this is an App config for the consumer, the subscribe. Alright, so, I would run this application. First of all, it will launch the publisher application and show you how this works. Let me review this, maybe I did not save. Alright, just give me a minute I need to put a loop around it. Actually, there is a loop. Alright, let me debug it. So, I don't have information to connect to this cache. So, let's figure this out. I have added my box so, please bear with me. Let me fix this issue real quick, it'll take a couple minutes. Although it added, maybe there was a typo. There you go. I was specifying our wrong cache name, my bad. Let me review the name right here. It’s pubsubcachewin.


I was using the cache name from yesterday which was a demo cache. It happens. Alright, I'm glad I was able to fix it quickly otherwise, would have been a total disaster. So, I think that we're good. So, this is going to launch the program, which is going to be the publisher.exe and it would publish ten messages. I'm publishing the same messages again and again. At this point publisher is started, the subscriber is not started as yet. So, let me show you the monitoring details.


There are some requests which are coming in, of course around this. But if you notice, there was my topic, that's the name 10.


Items are in there and then you should see those messages expired after the expiry time has been the elapsed and I think, I'm putting five minutes of expiry or more on that. I would now go ahead and publish a few more. There you go and you should have 10 items right here, extra added. So, 20 items in total and you can see message count going up.


So, that's the graph and you can see the same options in Windows performance monitor as well, where we have size and message count from 20 to 12 now. Primarily, because some have been expired. I think I'm using less expiry as part of that already. Let me see, I think, the message count is not showing correctly, let me see, I think this is, this should be 20 as per my monitor.

Run Subscribers

Let's review this with the help of the subscribers. Let's see how many messages it receives and by the way, I'm going to show you the code once I'm done with the demo.

So, it's supposed to get the existing messages and I think, it has gotten all of them in a random fashion. This is an asynchronous invocation of messages. It does not guarantee messages to be delivered in that order. So, you can receive first message at a later stage and so on and so forth.


And if I come back right here, we have message count drop to zero. I think this counter, let's review this one more time. I'm not sure if this represents the messages for a given topic or overall messages which are published. Alright, so, it's not showing the correct value whereas this should show. I think, those messages got received. So, I need to close the subscriber in order to achieve that. I'm going to run another subscriber. So, that you see messages being delivered to multiple one and I think then we'll conclude it and show you the code example for it. I'm going to enter few more messages, keep doing it and then on the subscriber side you can see 10 messages are received by this one and then a few more received by this one. If there are two delivery options, you can choose to broadcast messages to all these subscribers or to any. Right, so, based on that whichever receives it, a message gets expired from the cache as well. So, that was a quick demo. Now, I'm going to show you the details around what is involved in order to publish a message? What are the features on the topic side? What are the features on the publisher side and what are features on the subscriber side? If there are any questions at this point, please let me know. I would be happy to answer those questions for you right now otherwise, I'm going to move on and show you the detailed architectural side of things.

Main Pub/Sub Interfaces in NCache

These are main interfaces within NCache.


We have topic. Again, it's a channel for communication. It contains list of subscribers and it relays published messages to itself to the connected subscribers.


Then we have message that's the main payload. The point of interest, the object of interest for subscribers. It’s serializable payload. It could be any object, it could be any message that you want to deliver, any data to be precise.


Publisher is the one which is an application which is publishing messages and it can receive an optional delivery status notification as well. Delivery status is something that you can choose to turn on, but as this decided earlier or as discussed earlier, publisher don't need to wait for message to be delivered. It can move on. So, optional delivery status is something that you can turn on as needed or you can turn it off.


Subscribers, they register itself for specific topic and getting all the messages.

So, let's review these one by one and diagram illustrates all what we just discussed.


Publisher creates messages, register events, send messages, topic and store messages, store subscribers and send messages. Subscribers subscribes and then receive message notifications.

NCache Pub/Sub Topic Interface

So, let's review topic interface. So, first of all, you can create an NCache Pub/Sub topic and then you can get connected to an existing topic as well or you can delete a topic as well. So, let's see what is involved in this interface right here? So, if I go to this publisher right here, I first need to go to the program and if you notice in this program, I am getting the cache name. I'm getting the topic name, which could be any topic that you can choose and I'm getting a message counter, which is a random message and then I have publisher.start method, which I've implemented and inside that I'm getting cache initialized, which means I'm going to get it connected to the cache and then I'm getting a create topic interface and if I come back right here, we have IMessagingService. So, if I quickly show you this right here.

IMessagingService Interface for managing Topics in NCache

namespace Alachisoft.NCache.Web.Caching
    public interface IMessagingService
        ITopic CreateTopic(string topicName);
        void DeleteTopic(string topicName);
        ITopic GetTopic(string topicName);

We have IMessagingService interface, which has a CreateTopic method, a DeleteTopic method to delete a topic and then GetTopic. Let's review these one-by-ones. So, messaging service we have created a topic or we can just get connected to an existing topic. What you really do is, you can also enable message deliver, delivery failure notification, if that's something that you would like to do. For example, you can set up a call-back right here and that call-back can in turn, it be invoked but that's an optional one. You don't necessarily need this, if you don't want to enable it. So, like I said earlier, message delivery notifications are optional ones, so you don't need to enable them as a must. It's entirely up to your use case, if you want to enable those, then you can go ahead and do it.

Then we have a publish method, which is a custom method for this application, a wrapper for this and then inside that what we're really doing is we are constructing a message and then we're using topic.publish message. So, this returns a message, a topic. Sort of a handle to that topic and then topic.publish is their actual method, if I quickly show you right here. This is an ITopic interface, which has a name, It can have a message count, it can have expiry time, which I'll show you in a bit and then it also have some call-backs on topic deleted, message delivery failure and then it allows you to have subscription for the topic and then publish messages to it as well and this is the first method that I wanted to showcase, is that you can use topic.publish and then if you notice that there is a delivery option as well. You can have deliver to all as a must or to any. So, that's message level, so, that's a delivery option for the messages delivered or send to that topic and then there's an optional last Boolean right here, let’s check this, what it's suggests? For this one, if you want to have any failure notification or not. So, in this case I am setting this to true but you can turn it off and if does, it would invoke the call-back on the publisher side accordingly.

So, we saw two methods here. You can create topic and similarly alongside that you can also get a topic as well. So, that's another method that you can use, alternatively. But, since I'm running this for the first time, so, I'm using create topic, publishing messages to the topic and then I can also delete the topic, if needed. So, these are some of the scenarios and as you can see these slides are showing the same examples alongside that.

Create Topic: Code snippet to create a new topic in distributed cache

string cacheName = "pubSubCache";
string topicName = "orderTopic";

Cache cache = NCache.InitializeCache(cacheName);


So, if you delete the topic, topic deleted call-back is going to be invoked and topic deleted call-back is one which from where you can notify your end-users or whatever information that you need to publish.

Delete Topic: Deletes an existing Topic distributed

string cacheName = "pubSubCache";
string topicName = "orderTopic";

Cache cache = NCache.InitializeCache(cacheName);


OnTopicDeleted callback: If registered, it will be triggered upon the Delete Topic call.

using (Subscriber subscriber = new Subscriber())
// Subscribes on it, using the provided cache-Id and the topic-name.

subscriber.OnTopicDeleted = TopicDeletedCallback;

static void TopicDeletedCallback(object sender, TopicDeleteEventArgs args)
 Console.WriteLine("Topic '{0}' deleted.", args.TopicName);

NCache Pub/Sub Message Interface

Let's have a look at the messaging interface and here we discuss that there is a message invalidation option, message received notifications, failure or receive, failure notification and then encryption and compression is supported as part of that. So, let's have a look at the IMessage Interface for that matter. So, we have a message right here.

namespace Alachisoft.NCache.Runtime.Caching
    public class Message : IMessage
        public Message(object payload, TimeSpan? timeSpan = null);

        public static TimeSpan NoExpiration { get; }
        public string MessageId { get; }
        public TimeSpan? ExpirationTime { get; set; }
        public object Payload { get; }
        public DateTime CreationTime { get; }

Let's see, what is available as part of that. So, first of all, we have a TimeSpan, you can choose NoExpiration or you can have a TimeSpan ExpirationTime right here to be specified as a message option and if I come back right here, if you notice we're setting some time based expiration on that as well, if you notice that this is being passed on right here and we have a timespan. So, this is being called by the program itself. So, we're giving “TimeSpan.FromMinutes(5)”. So, that essentially means that any topic which is not delivered, if there is no subscriber or subscribers got disconnected, that message is going to stay in the communication channel for the specified period of time. It's sort of a persistence, but since it's against the Pub/Sub platform to persist messages indefinitely, so time-base is the right option, where you persist messages for certain bit of time and after that you purge the store itself. Those messages aren't going to be individually expired from the communication channel as well and this expiry can be on the topic level itself. Topic itself can have its expiry or messages can have their individual expiry attached to them as well. So, that's something that you do and by the way if the publisher and subscribers are connected publisher publishes the messages and those are relayed right away. It doesn't wait for the expiry to happen. It won't keep it, if the message has been delivered. So, once message has been delivered, it gets out of the cache right away. So, that's how you set up expiry.

Then you also have some received notification on the messages. Those are something that I've shown you earlier on. For example, you can see delivery, “Publisher.MessageDeliveryFailure” notification and then you can also generate a message, success status from the message as well. So, that's another option that you can turn on as part of this and then message encryption and compression can also be done and that's something which is a no code change option. All you have to do is come to the cache itself, go to the options because everything is driven by NCache itself. So, you can enable compression and you can right click and choose hot apply configurations.


Compression is for objects which are bigger in size. Message’s payload is bigger in size so, you should turn on compression automatically and encryption is something which is another option right here. It would require that you enable encryption and for that you need to stop the communication channel first, stop the cache and then enable encryption. There are many providers that you can choose from and all the messages are going to be encrypted and only then sent back to the publisher and subscribers. I hope that was straightforward. So, message example is right here.

//Payload containing OrderId to be sent in message

Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";

//Create message with payload and expiration time set to 150 seconds

Message message = new Message(payload);
message.ExpirationTime = new TimeSpan(0, 0, 150);

You can use order, construct a message, set up some expiration time and then use “topic.publish” and provide that message to the right topic.

Message Received Notification

So, message received notification. On the subscriber side, I want to show you that as well.

Callback invoked when a message is published on the topic

string cacheName = "pubSubCache";
string topicName = "orderTopic";

Cache cache = NCache.InitializeCache(cacheName);

//Get Order topic
ITopic orderTopic = cache.MessagingService.GetTopic(topicName);

//Register subscribers for Order topic

ITopicSubscription ordSubscriber = orderTopic.CreateSubscription(messageReceivedCallback);

private void messageReceivedCallback(object sender, MessageEventArgs args)
              //perform operations
if (args.Message.Payload is Order ord)
              //perform operations

From subscriber’s standpoint, all you have to do is get connected to the cache to start off. Get connected to the topic using “_cache.MessagingService.GetTopic”. This was the method that I was showing you earlier on or you can create a topic, if it does exist and then you create subscription that allows you to receive message in a call-back and here is the message receive call-back. I think it should be right here in the program. Message receive call-back. So, this is going to be invoked each time a message is received. So, that completes the example right here.

Step by Step: Publish Message to Topic

So, step by step one more time. You initialize the Pub/Sub cache cluster, create a dedicated topic or get connected to an existing one. Register message delivery events if needed, that's an optional one. Create a message and publish to a separate topic. Enable expiration, enable delivery options as needed and that's a code which would help justify that.

public void PublishMessages()
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
ITopic orderTopic = cache.MessagingService.CreateTopic(topicName);

//Register message failure notification
orderTopic.MessageDeliveryFailure += FailureMessageReceived;

//Register topic deletion notification
orderTopic.OnTopicDeleted = TopicDeleted;

//Payload to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";

//Create message with Order and expiration time set to 150 seconds
Message orderMessage = new Message(orderPayload);
orderMessage.ExpirationTime = new TimeSpan(0, 0, 150);

//Publish message to all registered subscribers
//and register message delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);

And then on the subscriber side you get connected to the cache, get existing topic or create a new one. Create subscription for the topic for message receiving. Register events for receiving which are going to be async events and then unsubscribe from topic and also delete it, if you need to and delete event can be made part of it.

NCache Monitoring for Pub/Sub

Next few slides are going to be focused on the monitoring side of things. Let's review these in totality. We've already covered the basic details within the PerfMon counter support for NCache, we have different options within the dashboard. Let's create another dashboard.


Let's have all of these added to it. So, we have some topic statistics as well. For example, we have topic statistics, which I’ve showed you already. Topic count, number of topics that you have. Message count. Message store size, which are the total size and bytes for the topic and this is very important for capacity building. If you're trying to understand how many messages are being delivered or published so, you can drag and drop message published per second and message delivered per second and then you can have some message expiry status as well as part of that. So, these are some of the counters. If I run the sample application one more time you would see activity on all of these. Alright, I'm going to keep putting some load by hitting enter multiple times and if I come back right here, you can see activities on all of them.


There are 220 messages. Topic count is 1 at this point. Message count is about 220. Message store sizes is showing as well. Messages are published. But there is no message which got delivered and there are no messages which are expired and if I just run a subscriber, it'll be real quick, you would see that those messages are going to be received as well. There you go and if I come back right here, now you should see activity here as well. Messages are received as well.


So, this completes the process you can log these counters to see capacity, to see the overall topics that are there, messages there, size of the store and expiry of those messages as well and I can create as many topics as I need to based on my requirements. Same counters are available on Windows PerfMon as well. So, you have the same set here and additionally you also have some PowerShell Cmdlets. For example, if you go to our documentation right here, let me open it real quick. So, we have three different options, PerfMon Counters, NCache Monitor and PowerShell Cmdlets. In some cases, you just want to rely on tools. So, for that purpose you can use our documentation and inside our PowerShell guide, let's see, if I can search it real quick. It gave me a general link, so, let me just see some monitoring options right here. So, you can see “Get-Topics”, that's a PowerShell Cmdlet, which allows you to get topic names based on the cache name. For example, if I open PowerShell right here. I can use this command, let me just open it on this side so, it's clear. Alright, so, for example, I can run it from any box right here and then pubSubCachewin is the name of the cache. It would give me nothing. I need to run it on the server itself because I think it's not, pubSubCachewin, there you go. My topic, Subscribers, Publisher and Message Count.


The reason to start working from my box because it needs an IP address to know where the cache exists. So, there are some tools on the PowerShell side of things, which allow you to see some statistics as needed. So, that completes the demo portion. Please, let me know if there any questions. I'm going to spend some time towards the end for details around the architecture or what is being offered as part of this communication channel, NCache as a messaging platform and why NCache is a better fit?

Distributed Cache Architecture

First of all, NCache is Open Source. So, you can get started and Pub/Sub is available even in an Open Source version of NCache. It's linearly scalable, that's the number one point and before that it's in-memory, That's the main point of interest for applications which are seeking only performance and they're not looking to have high load requirements to start out. So, if there is a performance issue NCache again is a better fit in comparison to conventional Pub/Sub messaging platforms.

It's linearly scalable, which essentially means that you can add as many servers as you need to. Two servers are good enough. But if they hit capacity because capacity can be hit by NCache servers as well. The initial problem that you saw with database. We're not saying that NCache would not see this problem. With one server you can hit a capacity and for that matter you can have more servers but those more servers could also add capacity. For example, those two servers are being maxed out and that's the right time because you know ahead of time about the load requirements or load being high on your application. So, you can sort of pre-empt this by adding more servers and make a better capacity planning. So, more servers can be added on the fly and that's the beauty of it where it's linearly scalable.

Then third important characteristic is that, if you need you can also have replication support and that would ensure reliability. It's already highly available and its server going down will not have an impact on the end clients or the publisher or subscriber’s platform would function without any issues. As long as you have one surviving node in the cache cluster, Pub/Sub platform will remain up and running and why it's able to do this? It's highly available because it's dynamic in nature.


It's a 100% peer-to-peer architectured cache cluster. That allows you to add as many servers as you need to and those servers are independent in nature. They contribute towards request handling capacity by distributing the load but they function in a 100% independent capacity. Any server going down or new server being added, would not have any impact on the cache. The platform does not need to be stopped for that. It can continue working and then clients don't need to be stopped or restarted. That's the issue with conventional sources, where if a server goes down you may have to restart clients in order to start using the surviving nodes. So, that's a dynamic in nature where clients would adjust automatically and cluster itself is 100% uptime with self-healing mechanism. If a server goes gets added, cluster adjust to that by distributing the load to the newly added server and notifying clients at the same time.


Similarly, the maintenance case or server going down case, where a server gets down or fails in that case, cache cluster remains up and running. You need one surviving node in order for this to function and clients are notified at runtime. Connection failover support is built into the client-side protocol. So, clients detect failures and then they failover and start using survival nodes automatically and that ensures a 100% uptime on the cache side and also for your end clients which are connected to it. So, it's dynamic in nature. It's 100% peer-to-peer architectured. Connection failover support is built into it and cluster is self healing within itself. It's a mechanism built into the protocol. That ensures it's 100% uptime, a highly available cache scenario.

Caching Topologies: Partitioned Cache

The topology of communication channels.


Pub/Sub platform can have partitioning of data. You can have data partitioned on Server 1 as well as on Server 2. These are data elements which are representing your messages. So, we have some messages delivered by Server 1 and some by Server 2. It's completely random, based on our distribution algorithm and your publisher and subscribers are connected to all the servers. So, some are connected to Server 1, some are connected to Server 2, but if you notice each server has, actually they’re connect to all of them but some messages are delivered by Server 1 and some by Server 2 and so on so forth. So, message load is going to be distributed and this is perform eccentric, where it fully utilizes all these servers memory capacity, for serving the messages, for storing the messages, for their expiration time and it also joins their computational power into a logical capacity as well. So, all these services contribute towards request handling capacity and this is the reason if you add more servers you get more capacity out of the system and that's why we recommend that you should use partition operation replica topology because you can linearly scale out, if you need to.

Caching Topologies: Partition-Replica Cache

This is partition replica cache, which has backup support as well.


We have Server 1 active partition, backup on (server) 2. So, all servers formulate an active partition and a backup partition of another server, which is a replica for other server. Server 1 is active backup on Sever 2, Sever 2 is active backup on 3 and Sever 3 is active backup on 1 and cluster is still able to manage this if a server goes down. Because, if Server 1 goes down, Server 1’s backup was on 2 so, this backup gets activated and it gets merged into Server 2 and 3 and cluster heals itself and formulates a 2 node active backup, active passive mechanism where Server 1 backup is on Server 2 backup is on Server 1. And, it's completely seamless to your end-users. You don't have to worry about end-users being affected by that. So, with 100% uptime NCache ensures all of this.

Alright, this brings us towards the end of our presentation. Please, let me know, we can focus towards the end on some of the questions that you guys may have. So, I would hand it over to Eddie at this point. Eddie you can pick it up from here. Again, thank you so much for your time. Hopefully it was beneficial and we look forward to seeing you again at our next webinar. In the interim, if you need to review the existing webinar, which you just reviewed online at Again a reminder, NCache is the only native application in the market today for maximum performance. Look forward to seeing you again soon. Thankyou.

What to Do Next?

© Copyright Alachisoft 2002 - . All rights reserved. NCache is a registered trademark of Diyatech Corp.