Skip to content

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Follow @CodeOpinion

Message-IDs for Handling Concurrency

This post serves as a guide for how you can use a Message identification (Message-IDs) on your messages (events and commands) to handle concurrency. This post is in a series related to messaging. The overview is available in my Message Properties post. YouTube If you haven’t already check out my YouTube channel. Message-IDs Each message, regardless of it being an event or a command, should contain a way to identify its specific instance of that message. This is as simple as adding a GUID/UUID to your messages: No other message (event/command) should ever use this ID (unless you’re also using… Read More »Message-IDs for Handling Concurrency

Roundup #65: CASPaxos, HealthChecks & Serilog, Fallback Policies, Playwright, F# Path to Relaxation

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter. CASPaxos: Linearizable databases without logs Recently I’ve been playing around with a new algorithm known as CASPaxos. In this post I’m going to talk about the algorithm and its potential benefits for distributed databases, particularly key-value stores. Link: https://reubenbond.github.io/posts/caspaxos Excluding health check endpoints from Serilog request logging In this post I show how to skip adding the summary log message completely for specific requests. This can be useful when you have an… Read More »Roundup #65: CASPaxos, HealthChecks & Serilog, Fallback Policies, Playwright, F# Path to Relaxation

Event Versioning Guidelines

This post serves as a guideline for how to handle versioning for messages, specifically in most cases, events. This Event Versioning Guidelines post is in a series related to messaging. You can find the overview in my Message Properties post. Backward Compatible Generally, adding additional properties to an event will not cause a versioning conflict with the event consumer. Meaning if we have a contract that defines the shape of our event, as long as we don’t break that contract, the existing event consumers will be able to process our new event and will ignore the additional properties. Also, if… Read More »Event Versioning Guidelines