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...
Link to the talk on YouTube:
I watch many software architecture talks (on-site and virtually), and I am starting to think that my understanding of software architecture differs from that of most speakers. I see a lot of talking about bounded contexts (as in Domain Driven Design), layers (as in Clean /Hexagonal/Onion Architecture), and dependencies (between classes, up-stream/down-stream contexts). Don’t get me wrong; these concepts are important. However, they are just a small part of all the aspects a software...
Evolutionary software architecture has gained much traction lately—at least in my bubble. It is one of my favourite topics, and I have presented and conducted workshops on it for over a decade. So, let me add a thought to the discussion:
The evolution of a software architecture has three dimensions:
Technical evolution,
conceptual evolution, and
the evolution of business capabilities
This work is licensed under a Creative Commons Attribution 4.0 International License.
Many thanks to bbv Software Services AG for making this blog post possible.
Many thanks to for making this blog post possible.
Many thanks to for making this blog post possible.