In part thirteen of this event sourcing series, we expand on set-remove-based bi-temporal events. In certain scenarios, we need to be able to undo events – typically because a user made a mistake. I’ll show you two approaches to solve this issue, why the “obvious” simple approach fails, and why we prefer one over the other.
We return to bi-temporal event sourcing in part twelve of my series on event sourcing. This time, we look at set-and-remove-based bi-temporal events – the second variant of bi-temporal events in our system. You’ll see why they are needed, and what additional problems this kind of event brings to the table.
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...
In part eleven of this series on event sourcing, we make a small detour to discuss consistency boundaries. I never thought much about this aspect until recently, when I watched a couple of conference talks that all made a big fuss about domain-driven design’s aggregates, and had a discussion with Sara Pellegrini about dynamic consistency boundaries. This post is less about the resulting solution we have and more about the reasoning that led to it (and that might lead to another solution...
TL;DR: Once a benchmark shows a win, put the optimized code back into the profiling harness. Compare the before and after memory and CPU profiles to see whether the larger execution path benefits too. A good benchmark table feels great. The before number is slower, the after number is faster, allocations drop, and the ratio looks impressive. After hours of staring at profiler stacks and benchmark output, that table feels like the finish line. Unfortunately, the table only describes the isolated...
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...
Event sourcing is easy. Just store what happened to a thing as events, and when you need the thing’s state, project the events. Unless it is not because there are misplaced or duplicated events in the event stream. In the tenth part of my event sourcing series, we’ll look at why events can be misplaced and how to handle them.
TL;DR: Useful benchmarks are controlled experiments. Copy the relevant production code, trim away unrelated work, choose realistic parameters, measure one responsibility, and use short runs for direction before spending time on full runs. Most benchmark examples look cleaner than the code we work with. Suspiciously cleaner. They compare string concatenation with StringBuilder. They call a static method. They pass one value in and return one value out. Those examples are useful for learning...
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...