TL;DR: Most workflows are better off accepting out-of-order delivery and modeling the business process to cope with it. If strict order is a real requirement, however, Azure Service Bus sessions are only the start. A delayed retry can let later messages overtake the failure. Preserving processing order then requires a hold-back that records the failed message in session state and refuses to process the backlog until that message succeeds. This post starts where my earlier Azure Service Bus...
TL;DR: Azure Service Bus can run an old and a new delivery path side by side while you migrate one event stream at a time. A delivery path is the route from a publisher, through a topic and subscription, to a consuming service. Create the new path before removing the old one, because duplicate delivery is easier to survive than message loss. This post is part of a short series on Azure Service Bus topology under load. The earlier posts explain filters, shared-topic contention, and failure...
TL;DR: Blast radius means how much unrelated traffic is affected when one messaging resource reaches a limit or stops making progress. If every event type shares one Azure Service Bus topic, a backed-up event stream can consume the shared topic budget and affect unrelated publishers. Splitting event streams across topics can make those failures easier to understand and contain. This post is part of a short series on Azure Service Bus topology under load. The earlier posts explain subscription...
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...
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...
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...
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...
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...
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...
In the fifth part of this event sourcing series, I’ll show you how we use compensation of events to handle failed commands and events that should never have happened. Sometimes, things go wrong – a command fails because the database is overloaded, there is a bug in the code for some edge case, the system is out of memory, the infrastructure misbehaves, etc. Or a user did something that should never have happened, like importing the wrong data set. When this happens, we want the...