Category Architecture

In Architecture, Cloud

2 weeks ago

7 Min read

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...

Read on

The scheduler is part of your message pump

2 months ago

10 Min read

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...

Read on

When the handler outlives the lease

2 months ago

15 Min read

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...

Read on

Message pumps fail in the transaction details

2 months ago

9 Min read

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...

Read on

A message queue bought us time

2 months ago

7 Min read

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...

Read on

Event Sourcing: compensation – the simple way out when things go wrong

In Architecture, Event Sourcing, F#

3 months ago

7 Min read

E

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...

Read on

Event Sourcing: You better Prevent long event streams

In .NET, Architecture, Event Sourcing

4 months ago

6 Min read

E

In the fourth part of my event sourcing series, we’ll take a look at why long event streams – streams with lots of events – are a problem and what options there are to deal with this problem. Why read models are not always enough to solve performance issues due to long event streams. And of course, I’ll discuss the involved trade-offs.

Read on

The Problem with Secondary Domain Events in Event Sourcing

In Architecture, Event Sourcing

5 months ago

4 Min read

T

We started using event sourcing over ten years ago. One of the hardest lessons was that there is a kind of events that is not obvious at first but have a big impact on your system design. I call this kind secondary domain events.

In this post, I’ll explain what secondary domain events are, and how they impact the design.

Read on

To test, or not to Test? Part 3 – Make it easier to recover from a defect