In this episode, we implement event publishing to Apache Kafka from the auth service, making use of Confluent’s .NET client package.

Microservices are all the rage for some time now, but are we using the right foundations to create them? In this post, we’ll look into a common design issue in distributed systems.

In this episode, we briefly introduce Apache Kafka, as we’ll use it to implement our event bus. We’ll focus on our specific use case, as Kafka can be used in a variety of scenarios. We’ll keep it in a developer’s perspective, not going much into more infrastructural subjects.

In this episode, we’ll implement the outbox publisher, or better yet, two versions of it, one better suited for lower latency and another for reliability. As we continue our event-driven path, this will be a good opportunity to introduce a couple of interesting .NET Core features: IHostedService (and BackgroundService) and System.Threading.Channels.

On the footsteps of the last episode, in this one we store the inferred events in the outbox table, doing so transactionally, so we have guarantees that any change will eventually result in a published event.

In this first step implementing event-driven integration between services, we’ll hook-up into EF Core’s infrastructure, namely when saving changes, to infer if any event should be raised based on the information provided by the change tracker.

As we start implementing event-driven integration, the first thing we need to do is publish the events. Although it might seem straightforward, there are some important things to consider in order to make it work reliably. In this episode, we discuss the challenges and introduce the transactional outbox pattern to help us facing these challenges.

In this episode, we take a look at the integration problem we have between services right now, go through some options to avoid or fix it, then have a quick overview of the solution we’ll be implementing in the coming episodes.

Following up on the last episode about the Optional type, we continue taking inspiration from functional languages and introduce Either and Error types, as a way to make the possible business logic outcomes more explicit and minimize using exceptions in non-exceptional situations.

In this post, we’ll make use of a concept most commonly associated with functional programming, the Optional type (aka Option or Maybe), in order to make our code safer and more explicit when expressing a lack of value, instead of leaning on the null reference, something that I’m sure has burned us many times in the past.