Modelon Solutions

I love queuing mechanisms, they allow you to decouple the input of a system from the output of a system, basically so they can be processed at different speeds relative to each other. They also usually come with retry mechanisms just because of the way they are build.

Service Bus is basically a FIFO. Things go in, and things get out in the order they went in. Consumers take an item from the queue, process it and then it gets removed. Azure allows you to define “Topics” instead of “Queues” so that you can have multiple readers (pub-sub concept) for a given item but it’s still the same relative process, read, process, remove.

Event Hub is a much nicer thing if you ask me because it is based on the concept of a stream and removal of items from this stream is independent from consumers processing it. Basically, publishers insert items into the stream and consumers are free to read from this stream from any starting point. Each reader has to maintain a pointer which indicates where they are in the stream and are free to move this pointer forward or backwards. This is great for things where you would like to replay items because you flushed a database somewhere. The catch is you have to maintain the size of stream to keep it at a manageable size. With storage so  cheap now it might be easier for some systems to just never delete items. If it’s a stream for IoT devices with millions of items per day, then maybe only the last 48 hours are relevant and readers who are not quick enough simply “miss out on some data”, which could be okay for some scenarios.

I am still new to this so if I make some over simplifications or errors, please let me know.

I can’t wait for building my first Azure Event Hub app which is not a prototype !