Loosely Coupled Show: Software Architecture and Design

Loosely Coupled Show

I’m excited to announce the Loosely Coupled Show, a new project I’m working on with James Hickey. Check out the YouTube Channel and subscribe!

The premise is simple. To have discussions about software architecture and design. The target audience is intermediate to senior software developers.

Episode #000

We recorded a quick video to kind of describe what the plan is for the show, check out our “first” episode for more about the show and us and our backgrounds.

Loosely Coupled Show

I’ve also posted a short video on my CodeOpinion YouTube channel to elaborate a bit more on the announcement, which you can check out as well.

Software Architecture and Design

I think at no matter what level you are in terms of experience in software development, architecture and design are something you already do. To what degree is what varies.

From how you organize code, define dependencies and even naming. They’re all different aspects of design.

There are many more advanced topics we’d like to talk about such as:

  • Top-level Architectures
  • Event Driven Architecture
  • Domain Driven Design
  • Service Boundaries
  • Microservices
  • Messaging
  • Concurrency
  • Fault Tolerance

And we can’t leave out the cloud. Yes, it’s just someone else’s computer but it’s a real enabler for new ways to build and deploy applications.

If you have any recommendations for specific topics you would like us to cover, or to recommend a guest, let me know on Twitter or in the comments!

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

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 a message owner). It’s a one time only usage that should be unique.

The producer of the event should be creating this ID before it publishes it. It shouldn’t be hydrated by some middle party.

Concurrency

Most systems support at least once messaging. Meaning, they will deliver a message to the consumer at least once. This means it can be delivered more than once.

Message handlers should be reentrant. You should be able to invoke multiple instances of a message handler concurrently and safely.

Meaning if the exact same instance of an InventoryAdjusted event was invoked twice (with the same ID), at the same time, the outcome would be the inventory on hand would increase by 10, not 20.

We can achieve this by having our message handler use the message ID apart of the same transaction it’s using apart of its state change.

Here’s an example using pseudo C#

The example above is using a unique key on Handler and MessageID columns in the Concurrency table. When we either try to insert the record or commit the transaction, it will fail if the unique constraint fails.

Events

Since an event can have multiple consumers/handlers is the reason why I’ve included the name of the handler as apart of the unique constraint. This is to demonstrate if you were using the same concurrency table for multiple handlers. In the case of event handlers, you want each handler to process the event, but not more than once each.

If you were using this for commands, you wouldn’t need to record the handler, just the MessageID.

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

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 endpoint that is hit a lot, where logging every request is of little value.

Link: https://andrewlock.net/using-serilog-aspnetcore-in-asp-net-core-3-excluding-health-check-endpoints-from-serilog-request-logging/

Globally Require Authenticated Users By Default Using Fallback Policies in ASP.NET Core

You can use Fallback Policies in ASP.NET Core 3.0+ to require an Authenticated User by default. Conceptually, you can think of this as adding an [Authorize] attribute by default to every single Controller and Razor Page ONLY WHEN no other attribute is specified on a Controller or Razor Page like [AllowAnonymous] or [Authorize(PolicyName="PolicyName")]).

Link: https://scottsauber.com/2020/01/20/globally-require-authenticated-users-by-default-using-fallback-policies-in-asp-net-core/

Playwright

Playwright is a Node library to automate the Chromium, WebKit and Firefox browsers. This includes support for the new Microsoft Edge browser, which is based on Chromium.

Link: https://github.com/microsoft/playwright/blob/master/README.md

The F# Path to Relaxation – and what it means for .NET

After all the talk this week about .NET and it’s liveliness, I recommend watching this talk, re: memetic independence

Link: https://www.youtube.com/watch?v=ZTbyKsw7uIU

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.