Coder Legion - Recent posts tagged rabbitmq

The Heart of B3: Building the Matching Engine with RabbitMQ, Redis and Spring Boot

Sun, 10 May 2026 21:29:07 +0000

Hello everyone!

Continuing the My Broker B3 series, we've reached one of the most anticipated components of the ecosystem: the B3 Matching Engine API.

In the previous post, we built b3-market-sync-api which synchronizes real prices from brapi.dev and stores them in Redis. Now it's time to use that data — this is the service that simulates the stock exchange itself, deciding whether a buy or sell order will be executed or rejected based on the prices we just put in cache.

️ What is the Matching Engine?

In the real world, when you place a buy order through your broker, it gets sent to B3, which checks whether there's a counterpart willing to trade at that price. This process is called matching.

In our simulator, the b3-matching-engine-api reproduces this logic in a simplified way:

Intake: Receives the order from the broker via RabbitMQ (queue mq-broker-to-b3)
Price: Fetches the current asset price from Redis (market:price:{TICKER}) — data injected by the Market Sync we built previously
Decision: Applies the matching rule
Persistence: Records the result in PostgreSQL
Notification: Returns the result to the broker via RabbitMQ (queue mq-b3-to-broker)

[Broker] ──RabbitMQ──▶ [mq-broker-to-b3] ──▶ [Matching Engine]
                                                      │
                                             Redis: market:price:{TICKER}
                                             (fed by Market Sync ⬆️)
                                                      │
                                         ┌────────────┴────────────┐
                                      FILLED                   REJECTED
                                         │                         │
                                   PostgreSQL                 PostgreSQL
                                         │                         │
                               [mq-b3-to-broker] ◀────────────────┘
                                         │
                                      [Broker]

MVP Focus

Before diving into the code, same disclaimer as previous posts: we're building the foundation. The goal is to have an end-to-end flow working with enough robustness to validate the POC.

In this phase, I prioritized:

End-to-end flow working correctly
Proper failure handling (no orders silently disappearing)
Dead Letter Queue for messages that fail during processing
REST API for querying execution history
Swagger documentation

️ Tech Stack

Technology	Usage
Java 21 + Spring Boot 3.5	Service core
Spring RabbitMQ	Order intake and result notification
Spring Data Redis	Real-time price lookup
Spring Data JPA + PostgreSQL	Execution persistence
Flyway	Database schema versioning
SpringDoc OpenAPI	Swagger UI documentation

️ Implementation Pillars

1. RabbitMQ Configuration

A critical lesson learned here: never rely on queues already existing in the broker. If the application starts before RabbitMQ has the queues created, the consumer fails on startup.

The solution is to declare all infrastructure beans directly in Spring — it ensures queues, exchanges and bindings exist before any message is processed:

@Bean
public DirectExchange exchange() {
    return new DirectExchange(exchangeName);
}

@Bean
public Queue queueIn() {
    return QueueBuilder.durable(queueIn)
            .withArgument("x-dead-letter-exchange", dlxName)
            .withArgument("x-dead-letter-routing-key", dlqName)
            .build();
}

@Bean
public Binding bindingQueueIn(Queue queueIn, DirectExchange exchange) {
    return BindingBuilder.bind(queueIn).to(exchange).with(routingKey);
}

Note the withArgument calls — they configure the Dead Letter Queue directly in the main queue declaration. Any message that fails processing is automatically redirected.

2. The Matching Logic

The heart of the service. The rule is straightforward:

BUY: If the price the user accepts to pay >= market price → FILLED
SELL: If the price the user wants to receive <= market price → FILLED
Otherwise → REJECTED

private static boolean isCanExecute(OrderEventDTO order, BigDecimal marketPrice) {
    if (SideStatus.BUY.name().equalsIgnoreCase(order.getSide())) {
        return order.getPrice().compareTo(marketPrice) >= 0;
    } else if (SideStatus.SELL.name().equalsIgnoreCase(order.getSide())) {
        return order.getPrice().compareTo(marketPrice) <= 0;
    }
    return false;
}

3. Failure Handling — No Silent Order Loss

A silent bug I identified: when the ticker wasn't in Redis, the method simply returned without doing anything. The broker would wait for a response that never came.

The fix was simple but critical — any failure must notify the broker:

if (marketDataOpt.isEmpty()) {
    log.warn("Price for ticker {} not found in Redis. Rejecting order {}",
             order.getTicker(), order.getOrderId());
    OrderResponseEvent response = new OrderResponseEvent(
        order.getOrderId(), ExecutionStatus.REJECTED.name(), BigDecimal.ZERO);
    orderProducer.sendToBroker(response);
    return;
}

This is exactly why we built b3-market-sync-api first. If Redis doesn't have the price, the order is immediately rejected — correct and predictable behavior.

4. Transactional Guarantee

Another critical point: persisting to PostgreSQL and publishing to RabbitMQ are two distinct operations. If the database saves but the publish fails, the execution is recorded but the broker is never notified — silent inconsistency.

The solution was adding @Transactional to the method that orchestrates both operations:

@Transactional
private void saveAndNotify(OrderEventDTO order, BigDecimal price, ExecutionStatus status) {
    // 1. Persists in PostgreSQL
    OrderExecution execution = OrderExecution.builder()
            .orderId(order.getOrderId())
            .ticker(order.getTicker())
            .side(SideStatus.valueOf(order.getSide()))
            .quantity(order.getQuantity())
            .executedPrice(price)
            .status(status)
            .build();
    repository.save(execution);

    // 2. Notifies the Broker
    OrderResponseEvent response = new OrderResponseEvent(
        order.getOrderId(), status.name(), price);
    orderProducer.sendToBroker(response);
}

5. Dead Letter Queue

For messages that fail in the consumer (unexpected processing error), we configured a full DLQ setup:

@Bean
public DirectExchange deadLetterExchange() {
    return new DirectExchange(dlxName);
}

@Bean
public Queue deadLetterQueue() {
    return QueueBuilder.durable(dlqName).build();
}

@Bean
public Binding bindingDlq(Queue deadLetterQueue, DirectExchange deadLetterExchange) {
    return BindingBuilder.bind(deadLetterQueue)
            .to(deadLetterExchange)
            .with(dlqName);
}

In the consumer, we rethrow the exception so RabbitMQ knows the message failed and routes it to the DLQ:

@RabbitListener(queues = "${app.rabbitmq.queue-in}")
public void receiveOrder(OrderEventDTO event) {
    log.info("New order received: ID {} | Ticker {} | Side {}",
            event.getOrderId(), event.getTicker(), event.getSide());
    try {
        matchingService.process(event);
    } catch (Exception e) {
        log.error("Failed to process order {}: {}", event.getOrderId(), e.getMessage(), e);
        throw e; // RabbitMQ routes to DLQ
    }
}

6. REST API + Swagger

Since the service exposes query endpoints, I configured Swagger UI from the start:

@Bean
public OpenAPI customOpenAPI() {
    return new OpenAPI()
            .info(new Info()
                    .title("B3 Matching Engine API")
                    .version("1.0.0")
                    .description("Simulates the B3 stock exchange matching engine..."));
}

Available endpoints:

Method	Endpoint	Description
GET	`/api/v1/executions`	List all executions
GET	`/api/v1/executions/order/{orderId}`	Find by order ID
GET	`/api/v1/executions/ticker/{ticker}`	Find by ticker
GET	`/api/v1/executions/status/{status}`	Find by status

✅ Validating the Execution

With the application running locally, all components started correctly:

✅ Flyway applied the order_executions table migration
✅ Hibernate validated the schema
✅ RabbitMQ connected with queues and DLQ declared
✅ Tomcat running on port 8091
✅ Swagger UI accessible at http://localhost:8091/swagger-ui.html

What's Next?

With b3-market-sync-api feeding Redis and b3-matching-engine-api ready to process orders, the entire B3 side is operational.

The next step is building the broker-order-api — the orchestrator on the broker side that will manage the complete order lifecycle:

Receive the buy/sell intent from the user
Validate the ticker via REST against broker-asset-api
Save the order as PENDING
Publish the event to Kafka
Send the order to the Matching Engine via RabbitMQ
Consume the feedback and update the final status

Once that service is ready, we'll have the first complete end-to-end flow running in the ecosystem.

Got any questions about the matching logic or RabbitMQ DLQ configuration? Drop them in the comments!

About the Series

⬅️ Previous Post: Syncing the Real Market: Consuming Brapi and Feeding Redis with Spring Boot

Series Index: Series Roadmap

Links:

Understanding RabbitMQ in Real-World .NET Systems: Why, When, and How to Use It

Wed, 21 Jan 2026 05:38:26 +0000

Most teams don’t start with RabbitMQ.

They add it when something begins to hurt.

Requests become slow.
Failures spread across services.
One small issue takes down multiple parts of the system.

That’s usually when RabbitMQ enters the picture.

This article explains what RabbitMQ actually solves, how to think about it from a senior-engineer perspective, and includes simple .NET examples to make the ideas concrete.

No heavy theory.
No marketing language.
Just practical understanding.

The Real Problem RabbitMQ Solves

RabbitMQ solves tight coupling between systems.

Without a message queue, systems usually communicate like this:

“Do this now, and I’ll wait for the result.”

That works—until it doesn’t.

With RabbitMQ, communication changes to:

“Here’s a message. Process it when you’re ready.”

This small shift has a big impact:
•Users don’t wait
•Failures don’t spread
•Systems become more resilient

RabbitMQ creates space between components, and that space matters.

A Simple Real-World Scenario

Imagine a .NET API where a user places an order.

Behind the scenes, you need to:
•send a confirmation email
•update inventory
•notify another service

If everything happens synchronously:
•the API gets slower
•one failure breaks the entire flow
•retries become complicated

With RabbitMQ:
•the order is accepted immediately
•background work happens later
•each task runs independently

The user moves on.
The system stays calm.

How RabbitMQ Works (Without Jargon)

At a high level, the flow looks like this:

Producer → Exchange → Queue → Consumer

In practice:
•Your .NET API publishes a message
•RabbitMQ stores it safely
•A background service consumes and processes it

The producer does not need to know:
•who consumes the message
•how long it takes
•whether it fails temporarily

That decoupling is the real value.

Publishing a Message in .NET (Simple Example)

Here’s a minimal C# example using RabbitMQ.Client.

var factory = new ConnectionFactory
{
    HostName = "localhost"
};

using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

channel.QueueDeclare(
    queue: "order.created",
    durable: true,
    exclusive: false,
    autoDelete: false,
    arguments: null
);

var message = "Order 123 created";
var body = Encoding.UTF8.GetBytes(message);

channel.BasicPublish(
    exchange: "",
    routingKey: "order.created",
    basicProperties: null,
    body: body
);

What matters here is not the syntax.

What matters is this:
The API sends a message and continues its work.

Consuming Messages in .NET (Background Worker)

Now let’s look at a simple consumer.

var factory = new ConnectionFactory
{
    HostName = "localhost"
};

using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

channel.QueueDeclare(
    queue: "order.created",
    durable: true,
    exclusive: false,
    autoDelete: false,
    arguments: null
);

var consumer = new EventingBasicConsumer(channel);

consumer.Received += (sender, eventArgs) =>
{
    var body = eventArgs.Body.ToArray();
    var message = Encoding.UTF8.GetString(body);

    Console.WriteLine($"Processing: {message}");

    // Send email, update inventory, etc.
};

channel.BasicConsume(
    queue: "order.created",
    autoAck: true,
    consumer: consumer
);

Console.ReadLine();

This consumer:
•waits patiently
•processes messages when they arrive
•can be scaled independently

Why This Design Works Well

This pattern gives you:
•faster user responses
•fewer cascading failures
•better control over background tasks

If email sending fails:
•the order is still saved
•the message can be retried
•users are not blocked

That’s a real improvement, not just an architectural one.

When RabbitMQ Is a Good Choice

RabbitMQ works best when:
•work can be asynchronous
•reliability matters more than speed
•services should stay independent
•traffic comes in spikes

Common use cases:
•email and notification systems
•background jobs
•event-driven workflows
•system integrations

When RabbitMQ Is the Wrong Choice

RabbitMQ is not always the answer.

Avoid it when:
•the system is very small
•everything must be real-time
•the team can’t support extra infrastructure

Adding a message broker adds responsibility.
If the problem is simple, keep the solution simple.

Common Mistakes in Real Projects

Some mistakes show up again and again:
•Treating queues like databases
•Ignoring retries and dead-letter queues
•Writing consumers that aren’t idempotent
•Adding async everywhere without reason

RabbitMQ does not remove complexity.
It moves complexity to where it belongs.

RabbitMQ Is a Design Decision, Not a Tool Choice

Senior engineers don’t choose RabbitMQ because it’s popular.

They choose it because:
•boundaries are clear
•failures are contained
•systems become easier to reason about

RabbitMQ helps systems talk without depending on each other’s timing or health.

That separation is powerful.

Final Thoughts

RabbitMQ is quiet technology.

It doesn’t impress in demos.
It doesn’t make headlines.

But over time, it:
•reduces incidents
•improves reliability
•makes systems easier to operate

That’s why it stays.

Good systems are not fast because they rush.
They’re fast because they don’t block each other.

That’s the real lesson RabbitMQ teaches.

Thanks for reading

If you’re using RabbitMQ:
•What problem did it solve for you?
•What lesson did you learn the hard way?

Let’s discuss in the comments.

MassTransit in ASP.NET Core: A Practical Guide to Event-Driven .NET

Mon, 29 Sep 2025 09:25:53 +0000

MassTransit in ASP.NET Core: A Practical Guide to Event-Driven .NET
Intro

Event-driven architectures help teams decouple services, scale independently, and handle failures gracefully. MassTransit is a mature, open-source library that makes message-based workflows in .NET straightforward. This guide shows a minimal but production-ready setup in ASP.NET Core with RabbitMQ.

1) Install packages

From your Web API project:

dotnet add package MassTransit
dotnet add package MassTransit.RabbitMQ

(For Azure Service Bus use MassTransit.Azure.ServiceBus.Core instead.)

2) Define a message contract

Contracts should be versionable and live in a shared project.

public interface SubmitOrder
{
    Guid OrderId { get; }
    string CustomerId { get; }
    DateTime Timestamp { get; }
}

3) Create a consumer

using MassTransit;

public sealed class SubmitOrderConsumer : IConsumer<SubmitOrder>
{
    public async Task Consume(ConsumeContext<SubmitOrder> context)
    {
        var msg = context.Message;
        // Your domain logic here (idempotent!)
        Console.WriteLine($"Received SubmitOrder {msg.OrderId} for {msg.CustomerId}");
        await Task.CompletedTask;
    }
}

4) Configure MassTransit in Program.cs (.NET 9 minimal hosting)

RabbitMQ example with retries and health checks.

using MassTransit;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddMassTransit(cfg =>
{
    cfg.SetKebabCaseEndpointNameFormatter();

    cfg.AddConsumer<SubmitOrderConsumer>(c =>
    {
        // optional: configure consumer-level retry, etc.
    });

    cfg.UsingRabbitMq((context, bus) =>
    {
        bus.Host("rabbitmq", h =>
        {
            h.Username("guest");
            h.Password("guest");
        });

        bus.ReceiveEndpoint("submit-order-queue", e =>
        {
            e.ConfigureConsumeTopology = false; 
            e.ConfigureConsumer<SubmitOrderConsumer>(context);

            e.UseMessageRetry(r => r.Interval(3, TimeSpan.FromSeconds(5)));
            e.PrefetchCount = 16;
            e.ConcurrentMessageLimit = 8;
        });
    });
});

builder.Services.AddHealthChecks();

var app = builder.Build();
app.MapHealthChecks("/health");
app.MapGet("/", () => "OK");
app.Run();

Docker tip

If you run RabbitMQ locally via Docker:

docker run -d --hostname rabbit \
  -p 5672:5672 -p 15672:15672 \
  --name rabbitmq rabbitmq:3-management

UI is at http://localhost:15672 (guest/guest).

5) Publish a message (from a Controller or Service)

Inject IPublishEndpoint for pub/sub or ISendEndpointProvider for point-to-point.

using MassTransit;

public sealed class OrderAppService
{
    private readonly IPublishEndpoint _publish;
    public OrderAppService(IPublishEndpoint publish) => _publish = publish;

    public Task SubmitAsync(Guid orderId, string customerId)
        => _publish.Publish<SubmitOrder>(new
        {
            OrderId = orderId,
            CustomerId = customerId,
            Timestamp = DateTime.UtcNow
        });
}

Or via an endpoint (send to a specific queue):

public sealed class OrderSender
{
    private readonly ISendEndpointProvider _send;
    public OrderSender(ISendEndpointProvider send) => _send = send;

    public async Task SendAsync(Guid orderId, string customerId)
    {
        var endpoint = await _send.GetSendEndpoint(new Uri("queue:submit-order-queue"));
        await endpoint.Send<SubmitOrder>(new { OrderId = orderId, CustomerId = customerId, Timestamp = DateTime.UtcNow });
    }
}

6) Error handling, retries, and observability

Retries: use UseMessageRetry on endpoints or the bus. Prefer bounded retries with intervals or exponential backoff.

Poison messages: failed messages after retries land in _error queues automatically.

Health checks: expose /health and rely on container orchestration to restart unhealthy pods.

Idempotency: make consumers safe to reprocess (e.g., check a processed table or use dedup keys).

7) (Optional) Outbox & transactions

If you publish events within a DB transaction, consider an outbox pattern (MassTransit integrates with EFCore Outbox) to avoid dual-write issues and ensure at-least-once delivery without duplicates.

8) Azure Service Bus variant (quick sketch)

Swap the transport:

builder.Services.AddMassTransit(cfg =>
{
    cfg.AddConsumer<SubmitOrderConsumer>();

    cfg.UsingAzureServiceBus((context, bus) =>
    {
        bus.Host(builder.Configuration["ASB_CONNECTION"]!);

        bus.SubscriptionEndpoint<SubmitOrder>("submit-order-sub", e =>
        {
            e.ConfigureConsumer<SubmitOrderConsumer>(context);
            e.MaxConcurrentCalls = 8;
        });
    });
});

Conclusion

MassTransit keeps the happy path simple while giving you the tools for serious systems: retries, sagas, scheduling, observability, and transport flexibility. Start minimal, add policies as you learn your failure modes, and keep consumers idempotent.

Building a Pub/Sub System in .NET: MassTransit, Reactive Extensions, and BlockingCollection

Tue, 26 Aug 2025 13:57:29 +0000

Modern applications often need to broadcast events across multiple services.
Think of an order being placed in an e-commerce system. The order service publishes an event, and multiple subscribers react independently:

the billing service charges the customer,
the email service sends a receipt,
the analytics service tracks the order.

This is the essence of the Publish/Subscribe (Pub/Sub) pattern.

In this post we’ll explore what it is, why it matters, and three implementations in .NET:

MassTransit with RabbitMQ (for distributed systems)

Reactive Extensions (Rx) (for in-memory event streams)

BlockingCollection (for producer/consumer pipelines)

What is the Pub/Sub Pattern

The Pub/Sub pattern decouples senders from receivers.
The Publisher creates a message (e.g., OrderSubmitted) and sends it
to a broker or channel.
The Broker delivers that message to all interested Subscribers.

Each Subscriber receives a copy of the message and processes it independently.

Benefits

Decoupling — publishers do not know subscribers
Scalability — multiple subscribers can process in parallel
Flexibility — add or remove subscribers without changing the
publisher

Why it matters

This pattern has been around for decades in middleware like IBM MQ, JMS, RabbitMQ, and Kafka.
It is fundamental in:

Event-driven microservices

Real-time systems (chat apps, trading platforms)
Notification and alerting systems
Data pipelines and analytics

IoT device communication

At its core, Pub/Sub enables loose coupling and asynchronous communication.

⚙️ Hosted Services in ASP.NET Core

A hosted service is a background task that runs with your app host.
In .NET you typically inherit from BackgroundService and implement ExecuteAsync.

public class SampleWorker : BackgroundService
{
    private readonly ILogger<SampleWorker> _log;
    public SampleWorker(ILogger<SampleWorker> log) => _log = log;

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        _log.LogInformation("Worker started");
        while (!ct.IsCancellationRequested)
        {
            // do work here
            await Task.Delay(TimeSpan.FromSeconds(5), ct);
        }
        _log.LogInformation("Worker stopping");
    }
}

// Register in Program.cs
builder.Services.AddHostedService<SampleWorker>();

In the MassTransit demo below, a PublisherService is implemented as a hosted service to periodically publish messages.

1️⃣ Pub/Sub with MassTransit and RabbitMQ

appsettings.json
{
  "RabbitMq": { "Host": "localhost", "Username": "guest", "Password": "guest" },
  "PublishIntervalSeconds": 5
}

OrderSubmitted.cs

namespace MassTransitDemo;

public record OrderSubmitted(Guid OrderId, string CustomerEmail, decimal Total);

OrderSubmittedConsumer.cs

using MassTransit;
using Microsoft.Extensions.Logging;

namespace MassTransitDemo;

public class OrderSubmittedConsumer(ILogger<OrderSubmittedConsumer> logger) : IConsumer<OrderSubmitted>
{
    public Task Consume(ConsumeContext<OrderSubmitted> context)
    {
        var m = context.Message;
        logger.LogInformation("Consumed OrderSubmitted, OrderId {OrderId}, Email {Email}, Total {Total}",
            m.OrderId, m.CustomerEmail, m.Total);
        return Task.CompletedTask;
    }
}

PublisherService.cs

using MassTransit;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

namespace MassTransitDemo;

public class PublisherOptions
{
    public int PublishIntervalSeconds { get; set; } = 5;
}

public class PublisherService(
    ILogger<PublisherService> logger,
    IPublishEndpoint publishEndpoint,
    IOptions<PublisherOptions> options) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        var delay = TimeSpan.FromSeconds(options.Value.PublishIntervalSeconds);
        logger.LogInformation("Publisher started, interval {Seconds}s", options.Value.PublishIntervalSeconds);

        while (!stoppingToken.IsCancellationRequested)
        {
            var msg = new OrderSubmitted(Guid.NewGuid(), "*Emails are not allowed*", Random.Shared.Next(50, 300));
            await publishEndpoint.Publish(msg, stoppingToken);
            logger.LogInformation("Published OrderSubmitted, OrderId {OrderId}", msg.OrderId);
            await Task.Delay(delay, stoppingToken);
        }

        logger.LogInformation("Publisher stopping");
    }
}

Program.cs

    using MassTransit;
    using MassTransitDemo;
    using Microsoft.Extensions.Configuration;
    using Microsoft.Extensions.Hosting;
    using Microsoft.Extensions.Logging;
    
    var builder = Host.CreateApplicationBuilder(args);
    
    builder.Configuration.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
    builder.Services.Configure<PublisherOptions>(builder.Configuration);
    
    builder.Services.AddMassTransit(mt =>
    {
        mt.AddConsumer<OrderSubmittedConsumer>();
    
        mt.UsingRabbitMq((ctx, cfg) =>
        {
            var section = builder.Configuration.GetSection("RabbitMq");
            cfg.Host(section["Host"], h =>
            {
                h.Username(section["Username"]);
                h.Password(section["Password"]);
            });
    
            cfg.ReceiveEndpoint("masstransitdemo-order-submitted", e =>
            {
                e.ConfigureConsumer<OrderSubmittedConsumer>(ctx);
            });
    
            cfg.UseMessageRetry(r => r.Interval(3, TimeSpan.FromSeconds(5)));
            cfg.UseInMemoryOutbox();
        });
    });
    
    builder.Services.AddHostedService<PublisherService>();
    
    builder.Logging.ClearProviders();
    builder.Logging.AddSimpleConsole(o =>
    {
        o.SingleLine = true;
        o.TimestampFormat = "HH:mm:ss ";
    });
    
    await builder.Build().RunAsync();

Run RabbitMQ

docker run -it --rm -p 5672:5672 -p 15672:15672 rabbitmq:3-management
# UI at http://localhost:15672  user guest  pass guest

MassTransit is a distributed application framework for message brokers like RabbitMQ and Azure Service Bus. It takes care of serialization, consumer lifecycle, retries, and endpoint setup.

2️⃣ Pub/Sub with Reactive Extensions (Rx)

Reactive Extensions (Rx)
is a library for composing asynchronous and event based programs with observable sequences.

Uses IObservable (event source) and IObserver (subscriber)

Provides LINQ-style operators (Where, Select, Buffer) for event streams

Perfect for in-memory event pipelines and UI scenarios

⚠️ Limitation: Rx is in-memory only. Events vanish when the app stops.

Program.cs

using System;
using System.Reactive.Linq;
using System.Reactive.Subjects;

public record OrderSubmitted(Guid OrderId, string CustomerEmail, decimal Total);

class Program
{
    static void Main()
    {
        var bus = new Subject<OrderSubmitted>();

        // Subscriber A
        var subA = bus.Subscribe(order =>
            Console.WriteLine($"[Email] Send receipt to {order.CustomerEmail}"));

        // Subscriber B with filter and transform
        var subB = bus
            .Where(o => o.Total >= 100)
            .Select(o => new { o.OrderId, Vat = o.Total * 0.24m })
            .Subscribe(x =>
                Console.WriteLine($"[Analytics] Order {x.OrderId}, VAT {x.Vat:F2}"));

        // Publish a few messages
        bus.OnNext(new OrderSubmitted(Guid.NewGuid(), "*Emails are not allowed*", 79.90m));
        bus.OnNext(new OrderSubmitted(Guid.NewGuid(), "*Emails are not allowed*", 149.00m));
        bus.OnNext(new OrderSubmitted(Guid.NewGuid(), "*Emails are not allowed*", 220.00m));

        bus.OnCompleted();
        subA.Dispose();
        subB.Dispose();
    }
}

3️⃣ Pub/Sub with BlockingCollection

BlockingCollection is a thread safe producer and consumer collection in .NET.

Supports blocking (consumers wait until data is available)

Supports bounding (limit capacity to avoid flooding)

Useful for background workers, pipelines, or batch processors

Program.cs

using System.Collections.Concurrent;

public record OrderSubmitted(Guid OrderId, string CustomerEmail, decimal Total);

class Program
{
    static async Task Main()
    {
        using var queue = new BlockingCollection<OrderSubmitted>(boundedCapacity: 100);

        // Subscriber A
        var emailTask = Task.Run(() =>
        {
            foreach (var order in queue.GetConsumingEnumerable())
                Console.WriteLine($"[Email] Send receipt to {order.CustomerEmail}");
        });

        // Subscriber B
        var analyticsTask = Task.Run(() =>
        {
            foreach (var order in queue.GetConsumingEnumerable())
                Console.WriteLine($"[Analytics] Track order {order.OrderId}, total {order.Total}");
        });

        // Publisher
        foreach (var price in new[] { 49.50m, 129.00m, 250.00m, 15.00m })
        {
            queue.Add(new OrderSubmitted(Guid.NewGuid(), $"user{price}@example.com", price));
        }

        queue.CompleteAdding();
        await Task.WhenAll(emailTask, analyticsTask);
    }
}

⚠️ Limitation: Only works inside a single process. No distribution.

References

MassTransit Documentation

MassTransit GitHub

RabbitMQ Tutorials

Microsoft Docs: Worker Services

Microsoft Docs: Publisher-Subscriber Pattern

System.Reactive GitHub

BlockingCollection Overview

✅ With these three approaches, you now have the full spectrum of Pub/Sub in .NET:

Lightweight in-memory streams with Rx and BlockingCollection

Robust distributed messaging with MassTransit and RabbitMQ

The Pub/Sub pattern has lasted decades because it makes systems more modular, more scalable, and more resilient to change.

Building an Order Processing Saga with MassTransit

Tue, 12 Aug 2025 09:22:53 +0000

MassTransit has been around since 2007 and has matured into one of the most stable and feature-rich open-source .NET messaging frameworks.

It acts like a factory for message brokers, meaning you can switch between providers such as RabbitMQ, Azure Service Bus, ActiveMQ, Amazon SQS, and others with minimal configuration changes.

This makes it ideal for enterprise-grade distributed systems where you want flexibility without vendor lock-in.

Why MassTransit?

Stability: Over a decade of continuous development and production use.

Multi-Broker Support: Easily swap between Azure Service Bus, RabbitMQ, Amazon SQS, etc., without rewriting business logic.

Developer Friendly: Built for .NET developers with excellent documentation and integration with DI, EF Core, and ASP.NET Core.

Advanced Features:

Outbox pattern
Request/Response messaging
Retry and circuit-breaker policies
Sagas and State Machines
Message scheduling

One of the Coolest Features: The State Machine

A State Machine allows you to model complex workflows where messages arrive in any order, but your application processes them in a controlled, state-aware sequence.

For example, in this Order Processing Saga:

An order is submitted.
The saga waits for stock confirmation.
If stock is reserved, the saga waits for payment authorization.
Once payment is authorized, the order is marked as completed.
If any step fails, the saga can transition to a failed state and trigger compensating actions.

This approach eliminates spaghetti code for multi-step processes and makes workflows easy to visualize and maintain.

Technology Stack Used in This Project
.NET 9

MassTransit (with Saga State Machine)
RabbitMQ (message broker)
PostgreSQL (saga persistence)
Entity Framework Core (database access)
Docker (local RabbitMQ/PostgreSQL setup)

Source Code
Full working implementation available here:
GitHub – OutboxSagaDemo

References

MassTransit Documentation – https://masstransit.io/

MassTransit GitHub Repository – https://github.com/MassTransit/MassTransit

MassTransit Saga State Machine Guide – https://masstransit.io/documentation/patterns/saga

RabbitMQ Documentation – https://www.rabbitmq.com/documentation.html

PostgreSQL Documentation – https://www.postgresql.org/docs/

Entity Framework Core Docs – https://learn.microsoft.com/en-us/ef/core/