Distributed Systems Design Fundamentals Q&A

00:07 Dan Kent

Hello, everyone. Thanks for joining us for another live webinar. This is Dan Kent. Today, I’m joined by my colleague and Solution Architect, Dennis van der Stelt, who’s going to answer your questions about the Distributed System Design Fundamentals course. A couple things that go over before we get started. First, we use the Q&A feature to ask your questions. So, any questions you might have just post in there and we’ll try to get to them as soon as we can. We’re going to attempt to try to answer all the questions in 60 minutes, but if we don’t get to them, we will answer them offline and make sure you get an answer. The second thing to go over is that the webinar is being recorded. So, we’ll make sure that you all get a link afterwards. With that we can get started. Go ahead, Dennis. Welcome.

00:55 Dennis van der Stelt

Thank you, Dan. And welcome to this Q&A. I’m just going to use this because I might switch some slides as well and I’m going to turn it off in a bit as well. I’m Dennis van der Stelt. A short disclaimer. I know Udi originally did the presentation, obviously the course, but this is obviously my experience and my perspective on things. So, I hope I don’t disagree with Udi too much. I don’t think I will, but I’ll try to answer all questions, but understand that since most of the questions are typed also in short sentences, I might misinterpret them. In any case, you are always free to contact me at my email address, Dennis.vanderstelt@particular.net, or you can even set up a conference call with me via this currently link. I’ll post that again at the end of the session.

But anyway, the reason I’m doing this Q&A with you is because I also attended the course. The full name of the course is Advanced Distributed Systems Design. I attended it in San Francisco in 2011. Didn’t really know what to expect, but I went to San Francisco and while I attended the course, I slowly got more and more excited and asked a lot of questions during it. And when I got back at the office, I really had struggles like how am I going to achieve everything and implement and practice everything that Udi was talking about during the course. And I’ll stop the sharing for a while so that you can see me.

So, I struggled implementing it. So, I can imagine that there are others that struggle with it as well. And that’s why we’re doing this Q&A. I had the opportunity to actually practice what Udi taught on a project I was working on at the moment. And I took one piece of work or requirements or other that I could implement. And I could have probably implemented it several hours. It was a really small piece, but I practiced on paper and a whiteboard to figure out what Udi told me and how to implement the stuff he taught me. I even took it home, wrote proof of concepts in C# (C-sharp). And instead of doing this within several hours, I think it took me three weeks to get it right. And I was so happy that I started doing way more.

And if you’ve read the email, it contained several links on how Udi Dahan pinged me on his own web block for a story of mine, to which I responded. And it was quite fun at the time. And from there, I started presenting and eventually started working for Udi and at Particular Software. And now I’m here doing this Q&A. So, let’s get started with some questions. We asked initially for some questions via email, and we got some pretty interesting questions. I’ll try to answer those. And after answering those, then is keeping track of the Q&A window and seeing if there are other questions that we can answer. One question came in that asked about Sagas and whether or not they were somewhat synonymous to long running processes. And he understood that long running processes should be self-contained but when using Sagas as an orchestrator that operates on multiple services. The output of the Saga is not just an event of what’s processed, but also the change in every service.

I was a little bit confused because there are several things in there, but I can tell that I struggled with Sagas initially myself. Sagas are indeed long running processes. Initially, I thought that Sagas could only take like, I don’t know, 10 minutes, maybe an hour, but in the end, when I fully embraced Sagas, I understood that they could basically even live forever. That is the possibility to basically clean up the Saga or complete the Saga, which basically means that the data in the database is gone. Udi explained also the event driven Saga, which is awaiting for several events, which is extremely useful. If you can’t predict the order of your messages, which is basically always impossible, but most of the time Saga represents a business process, or at least a part of the business process. And it is triggered by business events.

And those are the messages like order accepted for example. A business process, however, can be bigger than a Saga because Saga shouldn’t grow too big. Udi explained how basically a Saga is multiple message handlers with state. And if they grow too big, they become too complex. And you might want several Sagas to build the business process into Sagas. When Udi explains services themselves further and service boundaries in the full course, he also goes into how business processes can spend multiple services and that each service can have one or more Sagas that are part of the larger business process. So, mapping a Saga one-to-one to a business process, that’s not really the full story, especially when the person asking mention self-contained. The Saga itself is pretty self-contained and can only be influenced from outside using messages.

It was also mentioned briefly about the outcome of the change in every service, perhaps you mean that with every message data is added to the Saga and to outgoing messages. That’s not the idea of a Saga. And Udi explained that in the messaging module how that leads to tight coupling. So, I hope that clarified it a bit. And if not, you know now my email address. You can always contact me for further questions. Another question that came in said that the team was following Udi’s full course. So, not the modules that we’ve seen, but the full five day course, and they are implementing a system according to it, but they have lots of RPC, remote procedure calls, from one service to the other. And this causes issues in backend for front end services. This backend for front end services that’s a thing that Sam Newman talks about and it basically a service layer that sits in front of, for example, a web interface, a desktop interface, and another backend for front end service for a mobile app, because mobile apps need to take into consideration data, et cetera, et cetera.

The problem I think, is the word service with backend for front end services, which in the fundamental scores that you’ve watched, that you’ve all watched, Udi still hasn’t gone into, but he thinks, defines a service. And I also can’t really go into it because Udi takes about two to three days more to explain it. And I’m not on the re-assumption that I can do it like two to three minutes or something. I can only highly recommend watching the rest of the course, but I can say this, a service the way Udi talks about it is a logical thing. And the way Sam Newman talks about backend for front end services, is more technical.

The service Udi talks about is also much larger than you might expect. Within one of those logical services that Udi talks about, there’s quite some room for RPC calls and like Udi explains it’s not RPC or messaging, there’s no free lunch for either one of them. But RPC is like calling into a database. That’s also an RPC call and something none of us would consider bad or harmful. So, to answer your question, it’s hard to say from here, whether or not your team is doing the right thing or not implementing Udi, what Udi told them during the five day course, but RPC calls by themselves within service aren’t a bad thing.

Another question from the same person was, by creating a distributed system, we do not decrease the essential complexity. We only added accidental complexity. And I want to get back to the accidental complexity as well. I would say that indeed distributed systems are by default, maybe more complexities, even the best word, but Udi said it multiple times that Martin Fowler’s first rule of distributing object is don’t distribute your objects. And I sometimes hear people say, don’t distribute. That’s not the same, right? Distributing your objects to another service, a technical service, that’s something completely different from not distributing. However, I’ve built quite a few distributed systems because of various reasons. And usually they get a little bit more complex. They maybe not even more complex, they bring a new set of challenges that perhaps you haven’t had before. And the reason we still do it is because they provide benefits that we need and that we would otherwise not have.

I think I already mentioned it. Udi explain there’s no free lunch. Everything has trade offs. And he was clear on that with saying that, for example, batch’s jobs, they might have their place, but we use them too often. And sometimes replacing those with messaging can help tremendously. And I suggest you read the blog post on the particular.net website, Death to the Batch Job. It’s explain a lot of the benefits that doesn’t mean we should replace every single batch’s job with them.

What I experienced myself with the added complexity is that we also get many options to choose from, both in design, time and in production. And also for example, that the message handlers are usually pretty small with the results that there’s an incoming message and perhaps one or two outgoing messages, there are some database interaction and there’s all results in only a couple of lines of codes. And you can even ask new developers or junior developers to pick up those message handlers or write a message handler where a message is coming in, that the developer doesn’t even have to define itself. It’s already been defined because someone else is publishing the event for example, and they can easily pick up the task and write a message handler, and then slowly learn how messaging works, how your system works and it’s also easy to keep track of other developer does by a reviewing code, et cetera, et cetera. So, we get a new set of challenges. Possibly it becomes a little bit more complex, but I also think we get great benefits in the return.

Let’s see. Another question was, it’s difficult to understand what the real world system of services would look like? Do you have an example in a diagram? Well, that’s where I would like to go back to sharing my screen. I did prepare some stuff and Udi already mentioned it, right? The 4+1 Architectural view model. This is what it looks like. And it has several views, Logical view, Development view, etcetera. Don’t get hung up on those four views or their names. Because if you look at the Wikipedia article about the different views, it also says, for example, the Process view addresses- concurrency, distribution, integrator, performance, scalability, and this results in sequence diagrams, activity diagrams, et cetera. So, it’s not a single model that the Logical view presents a single model, the Development view gets a single model. All of them can consist of multiple diagrams.

And for example, what I often see in the past and currently is that people create a specific model. And it doesn’t really say anything about what the model represents. For example, this. Is this a Logical model? Probably not because there are databases involved, but it could also mean that this is part of a Deployment model, part of a Process model because there are lines and connections everywhere. But I have no idea what all these arrows actually mean, right? There’s probably some form of communication between them and here we can already see coupling between every single one of them and these services, the photo upload services, probably also something bigger. There are multiple classes in there, components, maybe multiple Visual Studio projects, I have no idea, including testing projects, etcetera, right? This single image doesn’t say anything. That doesn’t mean that, for example, I found another great image on the internet as well.

I’ve drawn those a lot as well, where I mixed several views into a single whiteboard drawing, simply because this is a way to communicate among architects and developers and whatnot about the model. Right? But once you start creating documentation, you should probably try to separate the different views from each other. And we have another workshop that is also loosely based on distributed design fundamentals and Udi Dahan’s five day course, Advanced Distributed Systems Design. It’s called the SOA Workshop or Service Oriented Architecture Done Right workshop.

And I haven’t got it open, I think, but you can find it here, github.com/Particular/Workshop, that are quite detailed instructions on how to get it working. And we have several exercises over here and I took the after example over here. And you can see, there are already quite a few projects in here and I loaded it up in visual studio and I’m not going to run it because you can do that yourself and whatever you see, it’s not that interesting, but you can see here and service this message handler where a website submits a submit order command and it stores some information inside a database and then this is more interesting. It publishes a new event, the order submitted event. And here you can see and I’ll bring back up, get up again. The project is called divergent because I am not that familiar with the word in English, but it means like something different, something else.

Here you can see the services, the way Udi describes them in the additional days, there’s a service customers, there’s a service finance, sales and shipping. Don’t get hung up on those names because this is not an actual domain. We just decided to select those names. But what it does is sales sends the event to shipping or sales publishes the event into whoever is interested and shipping and finance are interested in it. So for example, here you can see order submitted and what this does is also store some information into the database and then it sends initiate process commands to itself. And here’s the initiate process command handler. It’s also not that interesting. It calls a third party client and then publishes payments succeeded again event. And then it gets back to shipping where we have an actual Saga and here you can see the event driven part again where order submitted was the original event coming from sales. This is payment succeeded and just like Udi developed it or programed it during the course, which you were able to see, this is being processed and that’s it.

Now, how does this work inside a model? So, in this model, I explicitly combined several views, right? Here’s a website that submits the submit order to this message handler. This publishes the messages. Again, here, you can see the sales, shipping and finance services. You can see the third party. So this mixes Logical view where I would draw these services with Deployment view with multiple things. If I would separate them, I could have something like this. This is a message flow. See where a submit order comes in, an event is published. Both handlers accepted. This thing continues on. And here you can see that the order built handler, which was part of shipping should actually be much closer to this one because those are deployed together. But that doesn’t really matter in the message flow.

And if we go to a Deployment view, here you can see that, what is it, the dashed boxes. Those are NServiceBus endpoints. And here you can see that we’ve combined two message handler into this endpoint. So, we will deploy this to a server. We will deploy another finance endpoint to a server and decide and do correctly, this is sales. We’ll deploy this as well. Then this could be for example, a firewall. So you see that I already mixed here a little bit, the deployment of the end points with some network boundary fire wall thingy and the third party. And here you can see the services as Udi would define them. So, I highly recommend watching the other videos as well, but here you can see which messages flow through each logical service.

And you saw in visual studio here that a single service shipping or finance, for example, this already, without even having unit tests or whatever, contains five different visual studio projects. And here, for clarity, we combined everything into a single visual studio solution, so that you can literally press a five and everything starts up. And when you press a five, I think about 10 console windows startup, a single web interface and some other stuff. So, I hope that’s clear. And that’s it for the questions that arrived via email.

23:36 Dan Kent

Yes, we have another one. A couple actually related to request response patterns in sort of needing a real time response versus messaging. And they wanted some clarification on how you would deal with the real time nature of the requirement, but still using a sync message like sync process like messaging?

That’s a good question that gets asked a lot where, and with real time, I assume, because actual real time systems are something completely different. But with real time, I assume that you mean, for example, that a customer performs an action on the website and immediately would like an answer or a response whether or not, a good example again, and we use within Particular Software, a lot the retail industry or eCommerce websites, because it’s something that any of us can kind of understand the business domain enough. But for example, imagine that someone would like to order a book on Amazon or maybe three books. And if there are 10 left in store in the inventory of amazon.com, we would like to verify whether or not the books are available, and if they’re not available, immediately it responds back, “Sorry, you want to order three books, but they are not in stock anymore.”

The thing is, we got into this situation where basically both customers that are visiting our website or using our system and both the business, they expect our system to immediately return, excuse me, and answer because it’s my belief that this hasn’t always been the case. For example, what I always use is imagine a world where there are no computers. Then how would amazon.com accept orders and try to deliver the products back to the customer? It’s likely that you would phone Amazon and say, “Hey, I would really like this book, but I have no idea if it’s still in store and I want to pay for it and order it and get it delivered to my home.” If there is only one person on the phone, they could theoretically scroll through a lot of index cards on their desk or whatever, or walk to some closet where the inventory is being kept and say, “Well, we still have enough books, so you can order three.”

However, once you start scaling out, more and more people start calling in and we open up more phone lines and have more sales people on the phone. And then, we run into an issue because only one person at a time can look at the index cards related to books, for example, and check whether or not the inventory is still open enough to deliver the books, to be able to sell the books. And that’s when basically we start telling the customer saying, “Sorry, but I’d have to verify this for you and I can get back to you.” And that’s when we lose a real time response to the customer. And there are several ways to deal with this, to make it faster, make the response faster. But then with the nature of asynchronous communication, that messaging for example provides will always have to somehow deal with the response need not being in real time or being eventual consistent.

And it becomes much easier once you start embracing eventual consistency and start negotiating with the business, like how can we deal with this? Because for example, I don’t know, I can’t remember if Udi used the example during messaging or during the Saga module, where basically he talks about the Oprah effect. Imagine Oprah screaming, everyone should buy this book and suddenly, I don’t know, 300 million Americans or something, or maybe a little less, they start going to amazon.com and all wants to order the book. And there are several possibilities, either Amazon crashes because the database is too busy handling all the RPC calls or we build up a backlog of orders that maybe because we only had a stock of 100 books, we can’t fulfill every single order, but at least we’ll have options because sales can decide, “Hey, maybe we can back order all those books and provide them to everyone.”

But what Amazon actually does is they provide, what is it called in English, a voucher or a coupon, so that you can, they’ll say, “Hey, sorry, the book isn’t available, but here you have a coupon for, I don’t know, $25 to buy something else.” And even that has been a business decision with Amazon, because for example, almost everyone will use the coupon to buy something else worth of $25. Their business process also includes that if someone complains and says, “No, I don’t want to buy something else. I want either the book or my money back.” Then you’ll immediately get your money back. But that’s eventual consistency being embraced where more and more websites can’t immediately deliver or provide real time feedback because it’s extremely hard as Udi explains, to scale out, apologies, the database and it’s much easier to embrace eventual consistency and pick up those requests later and send an email saying, “Hey, your book is being delivered.” Or “I’m sorry, it’s not possible.”

I also gave a presentation about this once. I can’t remember if it’s on the Particular website, but it’s called, Dealing with Eventual Consistency. And yes, it is on the Particular website with a webinar recordings. It was another webinar I did. So, there I explained for an hour how to deal with eventual consistency and embrace it and how to discuss this with the business. So, I hope that answers your question.

31:10 Dan Kent

So, kind of expanding on that a little bit, our next question, this person’s having trouble convincing colleagues essentially of the value and investing time and effort in making these changes and trying to justify the cost benefit of the added complexity, sometimes the technical improvements that you have to do. And they’re just looking for some advice on how they might approach this better.

How to approach it better, I know Udi already explains some stuff. There’s one part Udi mentions that you should start off with, how does he call it? Start sending emails or creating PDFs when sending messages or embracing messaging. But myself, I didn’t do it that way. A company where they also had a very large monolithic system, but they didn’t have that many, how do you say this, entries into the backend where they basically submitted data or submitted an order. They did have a back office system where they submitted a lot of data, but from an end user perspective, they didn’t have that many, but it was failing quite often. And we would know that we would’ve basically lost the order, it wasn’t really an order, but for simplicity, I’ll use the word order.

We lost occasionally the order, which we didn’t really like, because, well, you can imagine why, and we started implementing messaging there. So it was only one point. And then the several times something would happen to the database or to service or whatever and messaging really saved us because we had a huge backlog of messages that would otherwise be RPC calls. So again, just like Udi says, try to start at the boundary or try to start at some part of the system that’s really, really important where messaging can help you save your bacon or whatever it’s called in proper English or American or whatever it is, and try to implement it there.

Other than that, embracing several things that Udi explains during the course, it’s very hard. The only thing I can say is try to start, another thing is try to start publishing messages at some point, maybe even without actually using the messages, but at some point in time, a feature will come along where you say, I know that there’s already a message that I can basically pick up because some business event happened. And now I only have to write this part of codes outside of the big monolith that we already have. And you’ll probably still have to query the database. Maybe you have to set up some synchronization of data so that you have the data that you need, but you can start developing small features outside of the big monolith. And that’s how I, in the past started breaking apart the big monolith.

So, maybe that helps as well and otherwise get in a consultant that advocates using messaging because consultants are usually pretty pricey. And because they cost one, $200 to $300 an hour. They usually tend to be right, because we pay a lot of money for them. So they probably are right because of that, but that tends to work as well.

35:42 Dan Kent

Okay. The next question, changing gears a little bit. They wanted some clarification and part of the coupling aspects, parts of the course, Udi talks about we tend to reinvent existing protocols over HTTP, and you mentioned trying other protocols, such as SMTP messaging and they’re looking for some, maybe some clarification on the aspect or expanding what he means exactly by that?

Could you, I’m not sure I understand the question.

36:20 Dan Kent

They’re asking, Udi talks about we tend to reinvent protocols using HTTP in our systems like we’re using HTTP for everything. And then we try to redo things that already exist. So, they’re looking for some clarification on what he means by that.

I can’t really remember what he says about it, but he talks about it in a way that we, for example, initially there were, when was it, was it .NET one even, or did it came out during the .NET 2.0 timeframe when web services were first introduced and they were in a speed of net and they were .ASMX web services, that’s basically what we call them, because they had that extension. And that was the first time when we started doing things over HTTP using XML and WSDL and XSDs and whatever. And after that came WCF who expanded on that and WCF could do much more than just HTTP, right? It could do named pipes, which was pretty fast. It could do TCP/IP and WCF could even do MSMQ, but almost everyone only used the HTTP part of it.

And then we basically threw away web services and WCF because they were bad technologies and they didn’t help bring us a better architecture or bring us, what was it, the high cohesion and low coupling that we’re searching for and then came things like REST and WEB API and I don’t know what else, which was again, basically the same RPC practices over HTTP, but now it was JSON because JSON was apparently new, according to a lot of people and so much better than XML. And for example, one of the things that always surprised me was that people said with JSON, I can add and remove properties on the fly and I can just send them over the wire and the other side will still accept and understand them, that wasn’t a part of JSON. That was something, a feature that the serializer provided because the very old XML serializer didn’t support that. But WCF already had that with the data contract serializer. So, WCF could already do that with XML and everything. But a lot of people thought that was one of the benefits of JSON and doing everything in REST and etcetera.

So, I think that’s what Udi intended, because I can’t remember exactly what he said about it, but I think that’s kind of what he meant. We continuously do things using RPC calls over HTTP and think they are a better technology and that they will help us build a system with a better architecture that is loosely coupled, etcetera, etcetera. But because we keep in the RPC space, that’s basically where we should let go, not for everything, because we’ve seen customers that embrace messaging and start doing messaging for everything. But, everything has its trade offs, right? So you should pick the technology that makes the most sense because it solves a problem that you’re facing. And I think that’s what he intended with. We keep reinventing protocols over HTTP.

40:40 Dan Kent

Okay. The next question they realized Udi already answered this question. They just want to hear your opinion too. The eight fallacies of distributed systems in the age of Cloud computing. Do you think that they’re all still relevant? Do you think the Cloud computing adds more fallacies? Want to hear your opinion on that?

I think they are still very relevant. So, if this is a yes or no question, then the answer is yes. Let me, I don’t know, I have this fallacies. I have the course open, but yeah, the network is reliable. That is always a great one. Because for example, what we’ve seen with the Cloud in the past, the network is reliable, is still an issue. Because first of all, what I’ve seen several times in the past is when a data center of Microsoft goes offline and it’s not like it shuts down like thousands or I don’t know how many servers, it’s usually the network connection towards the data center that starts breaking down. And, you notice when it comes back up again that inside the data center everything was just fine, but it’s the outside.

So, either users can’t access your website anymore. But if, for example, you have a mobile application, the application starts up, but it can’t access the data inside the data center anymore. So, the network isn’t reliable. But another thing like the network topology won’t change or what is it, it’s a difficult word for me to pronounce, the network is homogeneous. I don’t know how to pronounce that, but it’s like what you can also notice and one of the reasons why MSMQ in the Clouds doesn’t work, is because MSMQ only works on virtual machines. But this is the case with a lot of stuff inside the Cloud. The Cloud can basically decide that the virtual machine or the servers, and that could be an Azure function or AWS Lambda or whatever that is running on a specific machine, that machine is getting too busy or maybe the other way around, your function is the only thing running on that machine. So, it basically wants to replace it.

And I know that it might start up the same virtual machine or function on another machine before bringing down the other one. But it could be that you are trying to create a connection to a specific machine from, and especially within MSMQ, because you target virtual machines or servers explicitly with MSMQ and you start sending messages to those machine. And suddenly the Cloud decides and either Google or Microsoft Azure or AWS, they decide to take down the server and your message will never arrive. And with MSMQ this is explicitly visible because an outgoing queue with MSMQ because Udi explains that your servers first stores a message in the outgoing queue on the same machine, which means the queuing technology is basically always available. And then it starts sending that message in the backend to another server.

But imagine that server being taken away and replaced by another virtual machine with another IP address, then the messages will remain into the outgoing queue forever. This is less of an issue with other types of systems because you can have a load balancer and you start sending messages and suddenly the load balancer decides you can no longer access that machine, but another machine, but it could be that for example, you use session state on a machine and suddenly session state changes because you’ve never accessed that machine before. So yeah, all of the fallacies and I could go on probably for an hour or more, they still are very relevant in a Cloud computing. They might have changed a bit, however, but we still have to take into account every single one of them when we develop systems.

45:31 Dan Kent

Great. Getting towards the end here, but I think you can answer this question in time. We hear a lot about the event sourcing pattern, and there’s a lot of architects that prefer it’s use and everything throughout their systems. What are your thoughts on the pattern?

It’s hard to say how many people are using it. I don’t see it in the wild that often, but it’s even harder to say how many of them were successful and would recommend doing it again. Personally, I’ve spoken to a few people that implemented event sourcing, and there weren’t many that would say they do it again. And of those that say, they’d never do it again, it was almost always the added complexity that was unnecessary. So, I’ve talked before about the added complexity of distributed systems and messaging, but with event sourcing, they said it added a lot of complexity that was unnecessary and event sourcing, I don’t know those modules weren’t added to the free course, but Udi says it, event sourcing is an architectural style. It’s an option you have in your tool kit, you can use to build your better software whenever appropriate, right.

Perhaps event sourcing is a good option in certain circumstances. But for example, when you have a system where you just store comments, for example, on YouTube, I don’t know if you can edit those comments, but you can add comments and imagine that those comments they never change ever. Then what kind of benefit would event sourcing be? How useful is it to implement storing those comments using event sourcing? So, at the very least, I would say it’s not a top level architecture, and if you can use it, use it in the right place, don’t use it for everything. And Udi did a great keynote at event sourcing Europe in, it’s now, he did it in 2020. Oh, that was just before COVID hit us. That’s why I remember it. But the keynote is available. It’s probably somewhere on YouTube or on the domain driven design website.

So it was DDD Europe that had an additional day before DDD Europe started. And I recommend watching it because Udi explains where it comes from. And when he thinks it’s a usable architectural style and to give you a hint on what he tells you, I was at DDD Europe because it’s like an hour drive from my home. So, we had a Particular software booth there and I was manning the booth. And I can’t remember ever having that many discussions about a single keynote ever in my life. It’s definitely worth watching it.

48:58 Dan Kent

All right. Thank you. Lets see. I think we can fit maybe one more in. What are your thoughts on priority queues? They notice that it’s not a feature of NServiceBus and they like to know your opinion.

Yeah. It’s not a feature of NServiceBus. We get the question with Particular a lot that someone has an endpoint that receives messages, but the endpoint receives for example, five different type of messages. So, I don’t know, order accepted, order paid, customer became preferred, those kinds of messages. However, sometimes they want to process a message faster. And not only that it takes less time to process the message. But if there’s a backlog in the queue of, I don’t know, 100 messages and one of those 100 messages, is a high priority message, they want to pick out that single message and process it before all the other messages. And that is something that we do not support within NServiceBus and the reason for that is, is because usually it’s not just that you want to process the message faster than any other message, but there’s more business requirements behind it.

For example, an example that Udi uses in the course is, and he used to use to very familiar names, but I think he doesn’t use those any longer. I won’t use them either, but imagine there’s a high priority or a preferred customer and a regular customer and preferred customer always orders, I don’t know, 1 million apples and the regular customers only order like six apples at a time. Now you want to process this high, this preferred customer faster because he makes more money for you. But once he makes another order for, I don’t know, instead of 1 million apples, he wants to buy six oranges, do you still want to process him quicker than every other single customer? And maybe you want to ship to him faster as well. And maybe there are other business requirements that are specific to this preferred customer.

So, what we say at Particular Software is, you shouldn’t have a single endpoint handle this because maybe more messages [inaudible 00:51:56] and you send some of them to yourself and you would have yet another high priority queue, etcetera, etcetera. Instead, what you should do is set up another endpoint right next to it and have those process, the preferred customers or the high priority customers. Because in that case, you can decide better whether or not to process, because initially I said the regular endpoint is processing more than one message type, right? Also customer became preferred, order accepted, order paid or whatever. Do all five of those need to be processed high priority, or just one or two? You can make that decision when split out those two to the other one and then maybe sending an email, which is also in the regular one can be processed with regular processing power or speed or whatever.

And you can also decide to take the priority end point and put that on another server entirely where it gets more resources and maybe a faster database or more cash, or I don’t know, you can make all kinds of decisions if you split it out to an additional endpoint instead of having a single priority queue, which is a technical, only a small technical aspect of probably a much bigger, I don’t want to call it a problem, but a much bigger feature that you want to provide to your preferred customers or whatever it is that you want to process quicker. So, I hope that answers the question. Oh, and by the way, on my blog post, I also wrote a series of articles how you can technically also get multiple options solving this.

54:08 Dan Kent

All right. Well I think that’s all we have time for today. I want to reiterate that if you did ask a question, we didn’t get a chance to answer that we will answer them offline and make sure you get a response. Other than that on behalf of Dennis, this is Dan Kent saying goodbye and hope to catch you on the next webinar. Thank you.

Thanks, bye.

Distributed Systems Design Fundamentals Q&A

🔗Why watch?

🔗Some of the questions include:

🔗Transcription

About Dennis van der Stelt