TagAzure Service Bus

Azure Service Bus: One topic, many subscriptions

A

TL;DR: A single Azure Service Bus topic can be a reasonable starting point for one-to-many messaging. The topic receives published messages, and subscriptions provide separate delivery views for consumers. As the number of subscriptions, filters, and messages grows, the shared topic can become a place where routing work and storage pressure meet. Splitting event streams across topics may help, but adding entities alone does not accelerate a system. This post is part of a short series on Azure...

Azure Service Bus: Count your filters

A

TL;DR: Azure Service Bus can publish one message to a topic and deliver it to multiple consumers. A topic is the shared destination, a subscription is a consumer-specific view, and a filter decides whether a message is copied to that subscription. In high-throughput systems, the number of subscription rules can matter more than the filter type itself. This is the first post in a short series on Azure Service Bus topology under load. The series looks at filter count, subscription fan-out (one...

The scheduler is part of your message pump

T

TL;DR: The async model is a contract. In .NET, async methods are expected to do little CPU work, spend most of their time awaiting input/output, and make long-running CPU work explicit. Lease renewal depends on that contract. If a handler hides blocking or CPU-heavy work inside an async method, the scheduler assumptions behind renewal can fall apart. The message pump depends on the broker API, but it also depends on the runtime’s execution model. After publishing the previous article...

When the handler outlives the lease

W

TL;DR: A visibility timeout is a lease. It tries to keep two consumers from working on the same queue message at the same time, but only for a limited period. If message handling takes longer than that period, the pump must renew the lease while business code continues to run. That sounds like a small addition until renewal needs scheduling, cancellation, shutdown behavior, mutable pop receipts, delete coordination, and a policy for what to do when renewal fails. The first version of the...

Message pumps fail in the transaction details

M

TL;DR: Reading bytes from a queue is the easy part of a message pump. Things get difficult when message handling writes to a database, sends more messages, fails halfway through, moves to another broker, or runs in a cloud service with different transaction semantics. A small infrastructure project can quietly turn into a platform commitment. None of this looked particularly scary when we started. It looked like a loop: read from a queue, deserialize a message, find the handler, and call it. We...

A message queue bought us time

A

TL;DR: A queue can remove temporal coupling between a front end and a back end, but something still has to read the messages and run the business code behind them. That something is the message pump. Processing one message at a time protects downstream systems but increases queue wait time. Fire-and-forget processing looks faster until concurrency runs away. In practice, the pump needs an explicit limit. The medical invoicing system already worked. That made the request harder, not easier. It...

Azure Service Bus .NET SDK Deep Dive – Deduplication

A

Explains how de-duplication can help to make sure a message is only delivered once within a certain time period, for more posts in this series go to Contents. In the posts atomic sends and send via I showed ways to achieve atomicity for a group of messages or messages that are sent out as part of an outgoing message. Let’s have a look at a piece of code that looks super simply but might always behave like you’d wish it should behave: public async Task<IActionResult>...

Azure Service Bus .NET SDK Deep Dive – Sessions

A

Explains how message sessions can be used to de-multiplex interleaved message streams and guaranteed ordered delivery, for more posts in this series go to Contents. Usually, when someone asks what the characteristics of a queue is most people would say First-in, first out. The thing is though with regular Azure Service Bus queues that is not guaranteed. Simply because you might do concurrent receive operations on the same queue or a message that failed processing will be handled later due to...

Azure Service Bus .NET SDK Deep Dive – Transfer DLQ

A

Explains where messages go when they can’t be transferred to the destination, for more posts in this series go to Contents. A while ago, I introduced the concept of deadlettering messages in which I talked about where messages go in case of message expiry, reaching the maximum delivery count, or they were forcefully dead lettered. In the posts about atomic sends as well as send via, I showed how a transaction scope can be used to group send operations together into atomic units that...

Azure Service Bus .NET SDK Deep Dive – Runtime Information

A

Shows how to query runtime information using the management client, for more posts in this series go to Contents. Quite early in this series I introduced the ServiceBusAdministrationClient to create queues for example. Besides being able to create entities like queues, topics and subscriptions, the administration client provides the capability of querying runtime information from namespaces, queues, topics and subscriptions. The ability to query runtime information is quite handy for...

Recent Posts