Deep Dive into Multi-Tenancy

In the course of building systems, you’re frequently going to have a single logical system that needs to serve different sets of users or clients. Some examples I’ve run across have been systems that need to segregate data for different partner companies, different regions within the same company, or just flat out different users like online email services do today. You could just deploy completely different installations of your application for the different customers or groups within your company, but that's not likely going to scale very well.

Instead, let's do a deep dive into the idea of multi-tenancy, which roughly speaking is the ability for one deployed system to segregate data between multiple groups of users that we'll call "tenants" from here on out. We can do that either through using separate databases altogether for the different tenants, or we can somehow segregate tenant data within the same database.

As someone who both builds and supports development tooling for multi-tenancy and directly helps customers implement multi-tenancy, I'll do a deep dive on how decisions about multi-tenancy will effect your application's scalability or data security. I'll also show you ways to more easily accommodate multi-tenancy successfully in both web applications and asynchronous messaging throughout the entire application stack.

Advanced Event Sourcing

Marten is the most robust and feature rich solution for Event Sourcing in the .NET ecosystem. The Marten community got there through a lot of iteration and adaptation in reaction to the problems our community has faced in building real life systems using Event Sourcing.

In this talk, let me share some of these lessons and challenges by going quite a bit beyond basic introduction to Event Sourcing material and get into some harder problems you'll eventually need to solve in real systems like concurrency issues and some ways to protect your system.

Scalability and system responsiveness are of course real issues too, and I'll share some of the work the Marten community has done to improve both. A potential downside in Event Sourcing is the potential need for system downtime when event definitions or the read side "projections" need to change, so I'll discuss the recent abilities we've introduced to allow for "blue/green deployments" and how to get much closer to zero downtime deployments.

In all cases, I think the lessons learned from Marten in real usage and the approaches we've had to take will be applicable to any other platforms and tooling around event sourcing that you might be using today.

CQRS with Event Sourcing using the “Critter Stack”

Do you have a system where you think would be a good fit for a CQRS architecture that also uses Event Sourcing for at least part of its persistence strategy? Are you intimidated by the potential complexity of that kind of approach?

Fear not, using a combination of the Postgresql-backed Marten (https://martendb.io) library for event sourcing and its newer friend Wolverine (https://wolverine.netlify.app) for command handling and asynchronous messaging, I'll show you how you can quickly get started with both CQRS and Event Sourcing. Once we get past the quick start, I'll show you how the Critter Stack's unique approach to the "Decider" pattern will help you create robust command handlers with very little code ceremony while still enjoying easy testability.

Moving beyond basic command handling, I'll show you how to reliably subscribe to and publish the events or other messages created by your command handlers through Wolverine's durable outbox and direct subscriptions to Marten's event storage.

Concurrency and Parallelism in Real Life Development

Using the event sourcing support in the Marten library as a real world example, we're going to look at strategies to handle potential concurrency issues within our server side applications. We'll examine the usage of offline optimistic locking, serializable transactions, and very carefully use offline pessimistic locking.
Doing a deep dive into Marten's asynchronous event projection processing, I'll show some strategies for parallelizing work through the producer/consumer pattern. We'll also examine how Marten parallelized work through data sharding, leader election, and work assignment throughout an application cluster. Just to make things harder, we'll also talk about the necessary instrumentation and error handling it's taken to keep all that parallel work synchronized in the face of intermittent errors.

A Contrarian View of Software Architecture

I’ve spent an inordinate amount of time the past half decade across multiple companies working with very large, long running enterprise systems. Especially in long running, constantly changing systems, you want the code to be easy to understand, relatively painless to extend or modify, and when advantageous, be simple to modernize with updated technology. Unfortunately, the systems I’ve worked on have consistently failed to satisfy these goals.

Ironically enough though, my judgment is that the code in these systems has been hard to understand, extend or change, and modernize because they had all adopted much of the very industry conventional wisdom about how to build large, maintainable systems.

In particular, I want to demonstrate and explain how I think that prescriptive, layered architectural styles like Clean or Onion Architecture can actually cause harm in larger systems. I also want us to train our sights on how teams attempt to hide the actual persistence technology with “repository” abstractions and why I also think that’s harmful. I want us to shine a light on how teams fall down a trap of organizing code around business entities or data storage in ways that helps make the code in big systems hard to work with.

And of course, we’re going to talk about alternatives, or at least ways to ameliorate the potential problems with prescriptive architectural approaches. In particular, I’m going to show the shift to vertical slice architecture approaches for organizing code. I’m also going to examine ways to reduce code ceremony to improve code readability and use that to show the negative tradeoffs of using approaches like the Clean Architecture that mandate some elements of code ceremony to “force” developers into a consistent approach. And finally, we’re going to examine whether or not “consistency” should be a first class goal in code organization or architecture.

Resiliency in Asynchronous and Distributed Systems

I hate to break this to you, but your distributed systems are going to experience errors at runtime. External systems you depend on will be down, internal subsystems may be distressed, databases might be overloaded, and any operation that goes over a network is vulnerable to hiccups at runtime. You should also assume that your own system's code will occasionally encounter errors with who knows what unforeseen permutation of inputs or system state.

The reasonable goal we should strive for is a system that's resilient in the face of errors and can take the right error handling actions to prevent the system from getting into an inconsistent state by losing in flight work. Hopefully our systems can do this without requiring human intervention or downtime to fix issues related to system errors.

In this talk, we'll run through different types of runtime errors and match them with useful exception handling policies. We'll also make sure to understand when and where a transactional outbox and inbox makes sense within your system architecture. I'll be using Wolverine as the messaging framework for the samples, but the conceptual approaches should transfer to any other robust messaging tooling.

This will be the first delivery of this talk, but it's largely based on this blog post:

https://jeremydmiller.com/2022/09/06/developing-error-handling-strategies-for-asynchronous-messaging/