Aspire on dotnetuniversity

Wolverine: Transactional Messaging with RabbitMQ or Kafka, Inbox, Outbox, and Durable Local Queues

Sat, 02 May 2026 00:00:00 +0000

When we build microservices, the hard part is usually not publishing a message. The hard part is making database writes and message delivery behave correctly when failures happen between them. If a service stores data in PostgreSQL, publishes an integration event to RabbitMQ or Kafka, and also needs to update another store like MongoDB, we need a reliable way to keep those steps consistent without using a distributed transaction.

In this post, I want to show a practical way to solve that problem with Wolverine. The sample uses a small e-commerce system with two microservices, Catalogs and Orders, and demonstrates three important patterns together while keeping the broker selectable through configuration:

transactional outbox for publishing integration events after the database commit
durable inbox for idempotent downstream message consumption
durable local processing for internal work that should run after commit in a separate transaction

The sample is based on my Wolverine transactional messaging structure and uses a two-service e-commerce scenario with Catalog and Order. In the local blog sample, I kept the same architectural boundaries so the article stays practical: shared contracts, separate service projects, an Aspire AppHost, focused integration tests, and a transport switch between RabbitMQ and Kafka.

The Problem We Want to Solve

Assume Catalogs receives a request to create a product.

That request needs to do three things:

Store the product in PostgreSQL.
Publish ProductCreatedV1 so Orders can import that product through RabbitMQ or Kafka.
Update a MongoDB read model for query scenarios.

These three steps do not belong to one physical transaction:

PostgreSQL write uses one database transaction.
RabbitMQ or Kafka publish is external broker communication.
MongoDB projection should happen in a different persistence boundary.

If we do these steps manually in sequence, failures create inconsistent state very quickly:

product saved in PostgreSQL but event not published
event published but local transaction rolled back
product saved and event published but MongoDB projection failed
downstream service receives duplicate messages and writes duplicate records

This is exactly where Wolverine helps.

What Wolverine Gives Us

Wolverine is not only a message bus. It also gives us durable messaging primitives that fit very well with transactional application code.

For this scenario, the important capabilities are:

durable outgoing messages for outbox behavior
durable incoming messages for inbox behavior
durable local queues for internal post-commit processing
EF Core integration so message persistence can participate in the same PostgreSQL transaction as the write model

That means we can persist application data and outgoing work together, commit once, and let Wolverine flush the durable work only after the transaction succeeds.

Sample Scenario

The sample uses two microservices in an e-commerce domain:

Catalogs: write-side service for creating products
Orders: downstream consumer that imports product data from integration events

The flow is:

Catalogs receives POST /api/v1/catalogs/products.
Catalogs stores the product in PostgreSQL.
In the same transaction, Catalogs queues ProductCreatedV1 for the configured broker.
In the same transaction, Catalogs also queues an internal durable command named ProjectProductReadModel.
After commit, Wolverine dispatches both durable messages.
The local durable handler projects the product into MongoDB.
Orders consumes ProductCreatedV1 through a durable inbox and stores its own imported product record in PostgreSQL.

This gives us one transactional write boundary in Catalogs, one separate local processing boundary for MongoDB, and one separate consumer boundary in Orders.

Here is the sample API entry point that starts the flow:

// Thin endpoint — delegates to MediatR handler
internal static class CreateProductEndpoint
{
    internal static RouteHandlerBuilder MapCreateProductEndpoint(this IEndpointRouteBuilder endpoints)
        => endpoints.MapPost("/products", Handle).WithName("CreateProduct");

    private static async Task<CreatedAtRoute<CreateProductResponse>> Handle(
        [FromBody] CreateProductRequest request,
        IMediator mediator,
        CancellationToken cancellationToken)
    {
        var result = await mediator.Send(new CreateProductCommand(
            request.Name, request.Price, request.Stock,
            request.Category, request.Description), cancellationToken);

        return TypedResults.CreatedAtRoute(result, "CreateProduct", new { id = result.Id });
    }
}

The endpoint has one job: parse the HTTP request, build a command, send it through MediatR, and return the response.

Why Durable Local Processing Matters

This is the part many teams miss.

Sometimes we only think about external messaging, but internal asynchronous work can be just as important. In this sample, MongoDB projection is not an external integration event. It is internal application work, but it still should not run inside the same request transaction.

Why?

MongoDB is a different persistence technology.
We do not want the HTTP request to fail because a secondary projection store is temporarily unavailable.
We want the write model in PostgreSQL to stay the source of truth.
We still want reliable eventual consistency for the read model.

So instead of writing to MongoDB inline, Catalogs sends a durable local command after the PostgreSQL transaction is committed. That gives us a clean separation:

PostgreSQL write model is committed first.
MongoDB projection runs later in its own handler and its own persistence boundary.
If projection fails, Wolverine can retry it without losing the original business write.

This is what I mean by internal message processing in a transactional way. It is not one distributed transaction across PostgreSQL and MongoDB. It is a reliable post-commit workflow with durable local messaging.

Solution Structure

The sample keeps the structure close to a real microservice solution instead of putting everything in one demo project.

Main parts of the local sample:

src/Aspire/ECommerce.AppHost: Aspire orchestration entry point for catalogs-api, orders-api, PostgreSQL, MongoDB, and either RabbitMQ or Kafka depending on configuration
src/Services/Catalog/Catalog: write-side product logic and internal read-model projection flow
src/Services/Catalog/Catalog.Api: HTTP endpoints for creating products and reading write/read models
src/Services/Order/Order: downstream import logic with inbox-style duplicate protection
src/Services/Order/Order.Api: HTTP endpoints for importing and querying products in the order service
src/Shared/Contracts: MessageEnvelope<T>, ProductCreatedV1, and ProjectProductReadModel
src/BuildingBlocks/BuildingBlocks.Integration.Wolverine: shared Wolverine configuration with MediatR bridge for internal command dispatch
tests/Shared/Tests.Shared: shared end-to-end flow helper used by service tests
tests/Services/Catalog/Catalog.Tests: integration test for create + project flow
tests/Services/Order/Order.Tests: integration test for idempotent import behavior

This structure matters because the article is not only about Wolverine APIs. It is also about where to place contracts, handlers, persistence, and feature slices in a maintainable solution.

Each feature follows a consistent pattern with three files:

Command/Query (CreateProductCommand.cs): defines the request as a MediatR IRequest<TResponse> record
Handler (CreateProductHandler.cs): implements IRequestHandler<TRequest, TResponse> with the business logic
Endpoint (CreateProductEndpoint.cs): thin HTTP layer that injects IMediator and calls mediator.Send(command)

This keeps endpoints focused on HTTP concerns (routing, binding, status codes) while all business logic lives in MediatR handlers that are auto-discovered and testable in isolation.

The shared contracts are intentionally small and explicit:

public sealed record MessageEnvelope<TMessage>(
    Guid MessageId,
    Guid CorrelationId,
    DateTime OccurredAtUtc,
    TMessage Message)
{
    public static MessageEnvelope<TMessage> Create<TMessage>(
        TMessage message,
        Guid? correlationId = null,
        Guid? messageId = null,
        DateTime? occurredAtUtc = null)
        where TMessage : IMessage => new(
            messageId ?? Guid.NewGuid(),
            correlationId ?? Guid.NewGuid(),
            occurredAtUtc ?? DateTime.UtcNow,
            message);
}

public sealed record ProductCreatedV1(
    Guid Id,
    string Name,
    string Category,
    string Description,
    decimal Price,
    DateTime CreatedAtUtc)
    : IIntegrationEvent;

public sealed record ProjectProductReadModel(
    Guid ProductId,
    string Name,
    string Category,
    string Description,
    decimal Price)
    : IInternalCommand, IRequest;

System Architecture

The diagram below shows the full architecture with both services, the message broker, and both persistence stores:

flowchart TD classDef client fill:#a855f7,stroke:#7e22ce,color:#fff,font-size:14px classDef service fill:#06b6d4,stroke:#0891b2,color:#fff,font-size:14px classDef db fill:#f59e0b,stroke:#d97706,color:#fff,font-size:14px classDef broker fill:#10b981,stroke:#059669,color:#fff,font-size:14px classDef handler fill:#8b5cf6,stroke:#6d28d9,color:#fff,font-size:14px subgraph Client["🖥️ Client"] C1["HTTP Client"] end C1 --> EP1 subgraph Catalog["📦 Catalog Service"] direction TB EP1["POST /products"] H1["CreateProductHandler"] EB1["IEventBus \n📡 Publish"] DB1["PostgreSQL \nProducts + Outbox"] Outbox["📤 Bus Outbox \n📬 Drain & Deliver"] ICB1["IInternalCommandBus \n⚙️ Enqueue"] PH["ProjectReadModelHandler \n⚙️ Project"] MDB["MongoDB \nReadModels"] EP1 --> H1 H1 --> EB1 H1 --> DB1 H1 --> ICB1 DB1 -.-> Outbox Outbox --> B1 ICB1 --> PH PH --> MDB end subgraph Broker["📨 Message Broker"] B1{{"RabbitMQ / Kafka"}} end B1 --> C1C subgraph Order["📦 Order Service"] direction TB C1C["ProductCreatedConsumer \n🧩 Handler"] NH["NotificationHandler \n🧩 Handler"] DB2["PostgreSQL \nImportedProducts"] C1C --> NH NH --> DB2 end class C1 client class EP1,C1C service class H1,PH,NH handler class EB1,ICB1 service class DB1,DB2,Outbox,MDB db class B1 broker

Message Flow End to End

Let’s walk through the full request flow.

1. Catalogs receives product creation request

Catalogs exposes an endpoint like:

`1`	`POST /api/v1/catalogs/products`

The request creates a product in the write model.

In the sample, that endpoint delegates to a MediatR command through the thin CreateProductEndpoint: it receives the HTTP request, sends a CreateProductCommand through IMediator, and returns a CreatedAtRoute response. The handler then orchestrates the write model, integration event, and internal projection command.

2. MediatR handler orchestrates the write transaction

The actual business logic lives in the CreateProductHandler, which MediatR invokes when the endpoint sends a CreateProductCommand:

internal sealed class CreateProductHandler(
    CatalogsDbContext dbContext,
    IEventBus eventBus,
    IInternalCommandBus internalCommandBus)
    : IRequestHandler<CreateProductCommand, CreateProductResponse>
{
    public async Task<CreateProductResponse> Handle(CreateProductCommand request, CancellationToken cancellationToken)
    {
        var product = Product.Create(request.Name, request.Price, request.Stock);
        dbContext.Products.Add(product);

        var integrationEvent = MessageEnvelope.Create(new ProductCreatedV1(
            product.Id, product.Name, request.Category ?? string.Empty,
            request.Description ?? string.Empty, product.Price, product.CreatedAtUtc));

        await eventBus.PublishAsync(integrationEvent, cancellationToken);
        await dbContext.SaveChangesAsync(cancellationToken);

        await internalCommandBus.EnqueueAsync(new ProjectProductReadModel(
            product.Id, product.Name, request.Category ?? string.Empty,
            request.Description ?? string.Empty, product.Price), cancellationToken);

        return new CreateProductResponse(product.Id, product.Name, product.Price, product.Stock);
    }
}

The important point is not the exact syntax. The important point is the behavior:

product write is persisted in PostgreSQL
outgoing broker event is persisted durably
local projection command is persisted durably
commit happens once
Wolverine dispatches durable work only after commit succeeds

That is the outbox story. The handler brings the write model, integration event, and internal command into one persistence boundary.

The handler follows the same responsibilities in one MediatR pipeline:

persist the write model in PostgreSQL
publish the integration event through IEventBus (Wolverine outbox)
enqueue internal projection work through IInternalCommandBus (MediatR bridge)
SaveChangesAsync triggers the transactional outbox — Wolverine flushes durable messages only after commit

External Integration Event with RabbitMQ or Kafka

After commit, Wolverine publishes MessageEnvelope<ProductCreatedV1> to the configured broker.

In this sample, both APIs default to rabbitmq, but you can switch to kafka with configuration only. The application code does not need to change because the Wolverine transport wiring is selected in startup based on the configured transport.

If you run the APIs directly, set this in both API projects:

{
    "Messaging": {
        "Transport": "rabbitmq"
    }
}

Change the value to kafka to switch brokers.

If you run through Aspire, the AppHost reads Messaging__Transport, provisions only the selected broker container, and forwards the same value to both services.

1
2

$env:Messaging__Transport = "kafka"
dotnet run --project src/Aspire/ECommerce.AppHost/ECommerce.AppHost.csproj

Use rabbitmq instead of kafka to switch back.

Why wrap the event in a message envelope?

Because in real systems we usually need metadata such as:

message id
correlation id
causation id
message type
creation time
tracing or tenant information

A reusable MessageEnvelope<T> keeps transport-level and observability metadata consistent across services.

The sample envelope and event contracts look like this:

public sealed record MessageEnvelope<TMessage>(
    Guid MessageId,
    Guid CorrelationId,
    DateTime OccurredAtUtc,
    TMessage Message);

public sealed record ProductCreatedV1(
    Guid Id,
    string Name,
    string Category,
    string Description,
    decimal Price,
    DateTime CreatedAtUtc);

In this sample, Orders subscribes to the same event and imports the product into its own database.

That means Catalogs does not know anything about Orders internals. It only publishes an integration event.

Durable Inbox in Orders

On the consumer side, Orders uses Wolverine durable inbox semantics backed by PostgreSQL.

This solves a common problem in broker-based systems: duplicate delivery.

RabbitMQ and Kafka both require idempotent consumers. Consumers can crash after partially processing a message. Network failures can make delivery uncertain. Without inbox protection, the same event may create duplicate rows or duplicate side effects.

With a durable inbox:

incoming messages are tracked durably
processing can be retried safely
duplicate deliveries can be ignored or handled idempotently
the consumer can recover after crashes without losing message state

In the sample, Orders consumes ProductCreatedV1 and writes an imported product record to its own PostgreSQL database. That is a classic microservice integration pattern: each service owns its own data and builds its own local view from events.

The consumer follows a thin bridge pattern: a Wolverine handler receives the message from the transport and delegates to a MediatR notification handler for the actual business logic.

// Thin Wolverine bridge consumer — only delegates to MediatR
public sealed class ProductCreatedConsumer(IMediator mediator)
{
    public async Task Consume(MessageEnvelope<ProductCreatedV1> envelope)
        => await mediator.Publish(new ProductCreatedNotification(envelope));
}

The notification and its handler carry the actual business logic:

public sealed record ProductCreatedNotification(
    MessageEnvelope<ProductCreatedV1> Envelope) : INotification;

public sealed class ProductCreatedNotificationHandler(
    OrdersDbContext dbContext)
    : INotificationHandler<ProductCreatedNotification>
{
    public async Task Handle(
        ProductCreatedNotification notification,
        CancellationToken cancellationToken)
    {
        var message = notification.Envelope.Message;

        var existing = await dbContext.ImportedProducts
            .FirstOrDefaultAsync(x => x.Id == message.Id, cancellationToken);

        if (existing is null)
        {
            dbContext.ImportedProducts.Add(new ImportedProduct
            {
                Id = message.Id,
                Name = message.Name,
                Price = message.Price,
                Stock = message.Stock
            });
        }
        else
        {
            existing.Name = message.Name;
            existing.Price = message.Price;
            existing.Stock = message.Stock;
        }

        await dbContext.SaveChangesAsync(cancellationToken);
    }
}

This separation keeps the transport consumer minimal and testable. The Wolverine handler only does transport-specific work (deserialization, envelope extraction), and all business logic lives in the MediatR notification handler. Unit tests can test the handler directly without bootstrapping Wolverine.

On the Orders side, the endpoint that receives external integration events follows the same thin pattern — it publishes through IEventBus and returns immediately:

internal static class ReceiveProductCreatedEndpoint
{
    internal static RouteHandlerBuilder MapReceiveProductCreatedEndpoint(this IEndpointRouteBuilder endpoints)
        => endpoints.MapPost("/products/receive", Handle);

    private static async Task<Accepted> Handle(
        [FromBody] MessageEnvelope<ProductCreatedV1> envelope,
        IEventBus eventBus,
        CancellationToken cancellationToken)
    {
        await eventBus.PublishAsync(envelope, cancellationToken);
        return TypedResults.Accepted();
    }
}

Internal Durable Command for MongoDB Projection

Now back to the internal processor scenario.

After Catalogs commits the product in PostgreSQL, it also dispatches a durable local command:

public sealed record ProjectProductReadModel(
    Guid ProductId,
    string Name,
    string Category,
    string Description,
    decimal Price)
    : IInternalCommand, IRequest;

A local MediatR handler processes that command and upserts a MongoDB read model.

ProjectProductReadModel implements both IInternalCommand (for the IInternalCommandBus interface constraint) and IRequest (for MediatR dispatch):

And the handler implements IRequestHandler<ProjectProductReadModel>:

public class ProjectProductReadModelHandler(
    IProductReadRepository repository)
    : IRequestHandler<ProjectProductReadModel>
{
    public async Task Handle(
        ProjectProductReadModel command,
        CancellationToken cancellationToken)
    {
        var product = await repository.GetProductByIdAsync(
            command.ProductId, cancellationToken);

        await repository.UpsertProductAsync(new ProductReadModel
        {
            Id = product.Id,
            Name = product.Name,
            Price = product.Price,
            Stock = product.Stock
        }, cancellationToken);
    }
}

This handler runs outside the original HTTP request transaction.

That gives us several benefits:

MongoDB projection is retriable
request latency stays lower
PostgreSQL remains the transactional source of truth
projection failures do not corrupt the write transaction

To register the MediatR handlers, the module configuration uses AddMediatR instead of Wolverine’s ScanHandlers:

1
2
3

// CatalogModule.cs — MediatR replaces Wolverine handler discovery
builder.Services.AddMediatR(cfg =>
    cfg.RegisterServicesFromAssembly(typeof(CatalogsMetadata).Assembly));

The same applies to Orders, where MediatR is registered alongside Wolverine ScanHandlers for the thin transport consumer. Module prefixes for exchange/queue naming are shared via constants in MessagingConstants:

// MessagingConstants.cs — shared prefix constants
public static class ModulePrefixes
{
    public const string Catalog = "catalog";
    public const string Order = "order";
}

Using constants avoids hardcoded strings and makes the convention explicit across services:

// CatalogModule.cs — publisher: auto-derives "catalog" from assembly
builder.AddTransactionalWolverine(transport, cfg =>
    cfg.ScanIntegrationEvents(typeof(CatalogModule).Assembly));

// OrderModule.cs — consumer: references shared constant
builder.AddTransactionalWolverine(transport, cfg =>
    cfg.ListenToIntegrationEvents(
        MessagingConstants.ModulePrefixes.Catalog,
        typeof(ProductCreatedV1).Assembly));

This is a very useful pattern when one service needs to persist data in multiple stores but should only treat one of them as the primary transactional boundary.

In this sample, Wolverine is used exclusively as the transport layer for RabbitMQ or Kafka, while the local command dispatch is handled by MediatR. The WolverineInternalCommandBus bridges the two by accepting an internal command through Wolverine’s durable queue and forwarding it to MediatR:

internal sealed class WolverineInternalCommandBus(IMediator mediator) : IInternalCommandBus
{
    public async Task EnqueueAsync<TCommand>(TCommand command, CancellationToken cancellationToken = default)
        where TCommand : IInternalCommand
    {
        await mediator.Send(command, cancellationToken);
    }
}

This separation keeps Wolverine focused on reliable transport with transactional outbox/inbox while MediatR handles the in-process command dispatch with its pipeline behaviours, request/response semantics, and notification broadcasting.

The simplified sample implementation of that projection flow is:

public async Task ProjectReadModelAsync(ProjectProductReadModel command, CancellationToken cancellationToken = default)
{
    var product = await _writeStore.FindAsync(command.ProductId, cancellationToken)
        ?? throw new InvalidOperationException($"Product '{command.ProductId}' not found.");

    await _readStore.UpsertAsync(new ProductReadModel
    {
        Id = product.Id,
        Name = product.Name,
        Price = product.Price,
        Stock = product.Stock,
        SyncedAt = DateTime.UtcNow
    }, cancellationToken);
}

In the actual implementation, this method is encapsulated in the MediatR handler discussed above, so projection runs after commit with retries through Wolverine’s durable local queue.

Integration Tests

The sample includes focused integration tests so the transport switch is not only documented, but also verified.

The tests verify the business flow works with both supported transport values using TestContainers:

Catalog flow test — creates a product and verifies both the PostgreSQL write model and the MongoDB read model:

[Fact]
public async Task CreateAndProjectProduct_ShouldSucceed()
{
    var response = await Factory.CreateClient().PostAsJsonAsync(
        "/api/v1/catalogs/products",
        new CreateProductRequestDto("Test Product", 29.99m, 10, "corr-001"));

    response.EnsureSuccessStatusCode();

    await Task.Delay(500); // wait for async projection

    await ExecuteCatalogDbContextAsync(async dbContext =>
    {
        var product = await dbContext.Products.SingleAsync(x => x.Name == "Test Product");
        Assert.Equal(29.99m, product.Price);
    });

    await ExecuteMongoDbContextAsync(async mongo =>
    {
        var readModel = await mongo.ProductReadModels
            .Find(x => x.Name == "Test Product")
            .FirstOrDefaultAsync();
        Assert.NotNull(readModel);
    });
}

Order import tests — insert on first delivery, update on duplicate, and verify error handling for faulty payloads:

[Fact]
public async Task ConsumeProductCreated_ShouldInsert_WhenMissing()
{
    var envelope = MessageEnvelope.Create(new ProductCreatedV1(
        Guid.NewGuid(), "New Product", 19.99m, 5));

    var response = await Client.PostAsJsonAsync(
        "/api/v1/orders/products/receive", envelope);
    response.EnsureSuccessStatusCode();

    await Task.Delay(500);

    await ExecuteDbContextAsync(async db =>
    {
        var imported = await db.ImportedProducts
            .SingleAsync(x => x.Id == envelope.Message.Id);
        Assert.Equal("New Product", imported.Name);
    });
}

These tests make the article more concrete because they verify the most important outcomes:

the product is written and projected across PostgreSQL and MongoDB
duplicate messages update existing records idempotently
faulty payloads are rejected and moved to Wolverine’s error queue

There are also transport configuration tests that validate normalization and rejection of unsupported values. All integration tests use TestContainers with real PostgreSQL, MongoDB, and RabbitMQ or Kafka instances.

Conclusion

Transactional messaging is really about failure handling, not only message publishing. When one request needs to update a write model, publish an integration event, and trigger internal asynchronous work, Wolverine gives a clean way to model those steps with outbox, inbox, and durable local processing.

This sample shows how Wolverine can model transactional outbox, durable inbox, and durable local processing in a way that fits real microservice boundaries. RabbitMQ and Kafka stay interchangeable through configuration, the APIs are wired for both transports, and the tests keep the switching behavior covered.

You can find the sample code in this repository:

https://github.com/meysamhadeli/blog-samples/tree/main/wolverine-transactional-messaging-aspire

Reference

MassTransit: Transactional Messaging with RabbitMQ or Kafka, Inbox, Outbox, and Reliable Local Processing

Mon, 20 Apr 2026 00:00:00 +0000

When we build microservices, publishing a message is usually the easy part. The hard part is making sure database writes, integration events, and follow-up processing stay consistent when failures happen between those steps.

In this post, I want to show how to model that problem with MassTransit in a practical e-commerce sample. The sample uses two microservices, Catalog and Order. It demonstrates four things together:

transactional outbox style publishing after the database commit
durable inbox style duplicate protection on the consumer side
reliable local post-commit processing for internal work
transport switching between RabbitMQ and Kafka through configuration, with both API paths wired explicitly in MassTransit

The Problem We Want to Solve

Assume Catalog receives a request to create a product.

That request needs to do three things:

Store the product in PostgreSQL.
Publish ProductCreatedV1 so Order can import that product through RabbitMQ or Kafka.
Update a MongoDB read model for query scenarios.

These steps do not belong to one physical transaction:

PostgreSQL write uses one database transaction.
RabbitMQ or Kafka publish is external broker communication.
MongoDB projection belongs to a different persistence boundary.

If we do these steps manually in sequence, failures create inconsistent state quickly:

product saved in PostgreSQL but event not published
event published but local transaction rolled back
product saved and event published but MongoDB projection failed
downstream service receives duplicate messages and writes duplicate records

This is where transactional messaging patterns matter more than the broker itself.

What MassTransit Gives Us

MassTransit is a distributed application framework for .NET that gives us a clean abstraction over brokers like RabbitMQ and Kafka, plus middleware and patterns for reliable messaging.

For this scenario, the important capabilities are:

publish and send abstractions over multiple transports
consumer pipelines that support idempotent handling strategies
outbox-oriented patterns to avoid publish-before-commit problems
endpoint configuration that can stay stable while the transport changes

MassTransit does not magically create one distributed transaction across PostgreSQL, MongoDB, and the broker. Instead, it helps us structure the application so writes happen first, messages are emitted in a reliable way, and consumers can safely handle duplicates.

Here is how the EF Core transactional outbox works under the hood. The product write and the outbox message commit atomically in one database transaction. The bus outbox then delivers the message to RabbitMQ or Kafka in the background, while MediatR dispatches the read-model projection directly:

flowchart TD classDef client fill:#a855f7,stroke:#7e22ce,color:#fff,font-size:14px classDef service fill:#06b6d4,stroke:#0891b2,color:#fff,font-size:14px classDef db fill:#f59e0b,stroke:#d97706,color:#fff,font-size:14px classDef broker fill:#10b981,stroke:#059669,color:#fff,font-size:14px classDef handler fill:#8b5cf6,stroke:#6d28d9,color:#fff,font-size:14px subgraph Client["🖥️ Client"] C1["HTTP Client"] end C1 --> EP1 subgraph Catalog["📦 Catalog Service"] direction TB EP1["POST /products"] H1["CreateProductHandler"] EB1["IEventBus \n📡 Publish"] DB1["PostgreSQL \nProducts + Outbox"] Outbox["📤 Bus Outbox \n📬 Drain & Deliver"] PH["ProjectReadModelHandler \n⚙️ Project"] MDB["MongoDB \nReadModels"] EP1 --> H1 H1 --> EB1 H1 --> DB1 H1 --> PH DB1 -.-> Outbox PH --> MDB end Outbox --> B1 subgraph Broker["📨 Message Broker"] B1{{"RabbitMQ / Kafka"}} end B1 --> CON1 subgraph Order["📦 Order Service"] direction TB CON1["ProductCreatedConsumer \n🧩 IConsumer"] NH["NotificationHandler \n🧩 Handler"] DB2["PostgreSQL \nImportedProducts"] CON1 --> NH NH --> DB2 end class C1 client class EP1,CON1 service class H1,PH,NH handler class EB1 service class DB1,DB2,Outbox,MDB db class B1 broker

Sample Scenario

The sample uses two microservices in an e-commerce domain:

Catalog: write-side service for creating products
Order: downstream consumer that imports product data from integration events

The flow is:

Catalog receives POST /api/v1/catalogs/products.
The endpoint delegates to a MediatR handler, which creates a Product entity and publishes MessageEnvelope<ProductCreatedV1> via IEventBus.
SaveChangesAsync commits the product and the outbox message in one database transaction.
The handler dispatches a ProjectProductReadModel command through MediatR, which projects the read model to MongoDB.
The bus outbox delivers the integration event to RabbitMQ or Kafka in the background.
Order consumes ProductCreatedV1 and idempotently imports the product into its own PostgreSQL store.

Here is the actual endpoint handler. It is deliberately thin — it just extracts the request payload and delegates to MediatR:

internal static RouteHandlerBuilder MapCreateProductEndpoint(this IEndpointRouteBuilder endpoints)
    => endpoints.MapPost("/products", Handle).WithName("CreateProduct");

private static async Task<CreatedAtRoute<CreateProductResponse>> Handle(
    [FromBody] CreateProductRequest request,
    IMediator mediator, CancellationToken cancellationToken)
{
    var result = await mediator.Send(
        new CreateProductCommand(request.Name, request.Price, request.Stock), cancellationToken);
    return TypedResults.CreatedAtRoute(result, "CreateProduct", new { id = result.Id });
}

The handler runs the actual business logic — it creates the product, publishes the integration event through the EF Core outbox, dispatches the read-model projection, and returns the response:

internal sealed class CreateProductHandler(CatalogsDbContext dbContext, IEventBus eventBus, IMediator mediator)
    : IRequestHandler<CreateProductCommand, CreateProductResponse>
{
    public async Task<CreateProductResponse> Handle(CreateProductCommand command, CancellationToken cancellationToken)
    {
        var product = Product.Create(command.Name, command.Price, command.Stock);
        dbContext.Products.Add(product);

        var integrationEvent = MessageEnvelope.Create(new ProductCreatedV1(
            product.Id, product.Name, product.Price, product.Stock, product.CreatedAtUtc));

        // Publish through MassTransit bus (goes through EF outbox)
        await eventBus.PublishAsync(integrationEvent, cancellationToken);
        await dbContext.SaveChangesAsync(cancellationToken);

        // Project read model via MediatR
        await mediator.Send(new ProjectProductReadModel(
            product.Id, product.Name, product.Price, product.Stock, product.CreatedAtUtc), cancellationToken);

        return new CreateProductResponse(product.Id, product.Name, product.Price, product.Stock);
    }
}

Why Local Processing Still Matters

External messaging is only part of the story. Internal work like read-model projection can be just as important.

In this sample, MongoDB projection is not an integration event for another service. It is internal application work that should run after the database commit but still in the same request flow.

Why?

MongoDB is a different persistence technology that should not block the database transaction.
PostgreSQL should stay the source of truth for the write model.
The projection should happen after the commit so the write model is guaranteed to exist.

So the sample triggers projection as a MediatR command dispatched after SaveChangesAsync. The ProjectProductReadModel command flows through the same MediatR pipeline, just like any other request.

Solution Structure

The sample keeps the structure close to a real microservice solution instead of putting everything in one demo project.

Main parts of the local sample:

src/Aspire/ECommerce.AppHost: Aspire orchestration entry point for catalogs-api, orders-api, PostgreSQL, MongoDB, and either RabbitMQ or Kafka depending on configuration
src/Services/Catalog/ECommerce.Services.Catalogs: write-side product logic and internal read-model projection flow
src/Services/Catalog/ECommerce.Services.Catalogs.Api: HTTP endpoints for creating products and reading write/read models
src/Services/Order/ECommerce.Services.Orders: downstream import logic with inbox-style duplicate protection
src/Services/Order/ECommerce.Services.Orders.Api: HTTP endpoints for importing and querying products in the order service
src/Services/Shared/ECommerce.Services.Shared/Contracts: MessageEnvelope<T>, ProductCreatedV1, and ProjectProductReadModel
src/BuildingBlocks/BuildingBlocks.Integration.MassTransit: MassTransit wiring, outbox, MediatR-backed internal command bus
tests/Shared/Tests.Shared: shared test infrastructure (TestContainers for Postgres, MongoDB, RabbitMQ, Kafka)
tests/Services/Catalog/ECommerce.Services.Catalogs.IntegrationTests: integration test for create + project + outbox drain
tests/Services/Order/ECommerce.Services.Orders.IntegrationTests: integration tests for consumer error and dead-letter handling

The shared contracts are intentionally small and explicit. The envelope wraps every message with idempotency metadata, and the event and internal command carry the full product state needed by downstream consumers and the read-model projector:

public sealed record MessageEnvelope<TMessage>(
    Guid MessageId, Guid CorrelationId, DateTime OccurredAtUtc, TMessage Message
) : IMessageEnvelopeMetadata where TMessage : IMessage
{
    Type IMessageEnvelopeMetadata.MessageType => typeof(TMessage);
}

public static class MessageEnvelope
{
    public static MessageEnvelope<TMessage> Create<TMessage>(TMessage message,
        Guid? correlationId = null, Guid? messageId = null, DateTime? occurredAtUtc = null)
        where TMessage : IMessage => new(
            messageId ?? Guid.NewGuid(),
            correlationId ?? Guid.NewGuid(),
            occurredAtUtc ?? DateTime.UtcNow,
            message);
}

// Integration event — published to the broker for downstream services
public sealed record ProductCreatedV1(
    Guid ProductId, string Name, decimal Price, int Stock, DateTime CreatedAtUtc
) : IIntegrationEvent;

// Internal command — dispatched through MediatR, never leaves the service boundary
public sealed record ProjectProductReadModel(
    Guid ProductId, string Name, decimal Price, int Stock, DateTime CreatedAtUtc
) : IInternalCommand;

The Order consumer uses an upsert pattern for idempotency — if the product already exists in its local PostgreSQL, it updates rather than inserting a duplicate.

Here is the actual ProductCreatedConsumer implementation that powers this flow:

public sealed class ProductCreatedConsumer(OrdersDbContext dbContext)
    : IConsumer<MessageEnvelope<ProductCreatedV1>>
{
    public async Task Consume(ConsumeContext<MessageEnvelope<ProductCreatedV1>> context)
    {
        var message = context.Message.Message;
        if (string.Equals(message.Name, "faulty-product-created", StringComparison.OrdinalIgnoreCase))
            throw new InvalidOperationException(
                "Intentional consumer failure for retry and dead-letter tests.");

        var existing = await dbContext.ImportedProducts.SingleOrDefaultAsync(
            x => x.Id == message.ProductId, context.CancellationToken);

        if (existing is null)
            dbContext.ImportedProducts.Add(ImportedProduct.Create(
                message.ProductId, message.Name, message.Price, message.Stock, message.CreatedAtUtc));
        else
            existing.Update(message.Name, message.Price, message.Stock, message.CreatedAtUtc);

        await dbContext.SaveChangesAsync(context.CancellationToken);
    }
}

When the consumer throws for faulty-product-created, MassTransit moves the message to the error queue (RabbitMQ DLX) or the dead-letter topic (Kafka), and the integration tests verify no product is persisted in the database.

RabbitMQ or Kafka with the Same Application Flow

One useful part of MassTransit is that the application flow can stay stable while the transport changes.

In this sample, both APIs default to rabbitmq, and the APIs normalize and validate the configured transport in startup.

The current wiring is:

rabbitmq uses MassTransit RabbitMQ transport in both APIs
kafka uses a MassTransit Kafka rider with a producer in Catalog and a topic endpoint in Order

If you run the APIs directly, set this in both API projects:

{
    "Messaging": {
        "Transport": "rabbitmq"
    }
}

Or switch the configuration value to Kafka:

{
    "Messaging": {
        "Transport": "kafka"
    }
}

The Aspire AppHost reads the same setting and starts the matching broker container. In the application layer, MassTransit is configured from the same transport value so the switch stays centralized between RabbitMQ and Kafka.

The key point is that the application code never references RabbitMQ or Kafka types directly — it uses IEventBus and IConsumer<T>, and MassTransit maps them to the configured transport at startup.

Integration Tests

Like my other messaging samples, this one includes focused integration tests instead of only showing configuration snippets.

The Catalog integration test verifies the full flow end to end with live containers (PostgreSQL, MongoDB, RabbitMQ):

[Fact]
public async Task PostProduct_ShouldCreateWriteAndReadModels_AndPublishEvent()
{
    using var client = Factory.CreateClient();
    var request = new { name = "Test Basket", price = 15.25m, stock = 10 };

    // Act
    var response = await client.PostAsJsonAsync(
        "/api/v1/catalogs/products", request, cancellationToken);

    // Assert – HTTP
    Assert.Equal(HttpStatusCode.Created, response.StatusCode);

    // Assert – write model persisted in PostgreSQL
    await ExecuteCatalogsDbContextAsync(async dbContext =>
    {
        var entity = await dbContext.Products.FindAsync(created!.Id);
        Assert.NotNull(entity);
        Assert.Equal(request.name, entity!.Name);
    });

    // Assert – bus outbox drained (MassTransit delivered the event)
    Assert.True(await WaitForOutboxToDrainAsync(TimeSpan.FromSeconds(30)));

    // Assert – read model projected to MongoDB via MediatR
    var readModel = await WaitForMongoReadModelAsync(created!.Id);
    Assert.NotNull(readModel);
    Assert.Equal(request.name, readModel!.Name);
}

The Order integration tests verify fault handling for each transport. Here is the RabbitMQ error-queue test:

[Fact]
public async Task FaultyRabbitMqMessage_ShouldBeMovedToErrorQueue_WhenConsumerFails()
{
    var envelope = MessageEnvelope.Create(
        new ProductCreatedV1(
            Guid.NewGuid(), "faulty-product-created", 9.99m, 1, DateTime.UtcNow));

    var exception = await Assert.ThrowsAsync<InvalidOperationException>(
        () => InvokeProductCreatedConsumerAsync(envelope, cancellationToken));

    Assert.Equal(
        "Intentional consumer failure for retry and dead-letter tests.",
        exception.Message);
}

The Order tests also include an equivalent Kafka error-queue test and a verification that faulty messages do not persist any imported product.

There are also unit tests that cover individual behavior without infrastructure. Instead of testing consumers directly, the tests now test the MediatR handlers:

// Catalog — verifies handler calls UpsertAsync once
[Fact]
public async Task Handle_ShouldUpsertReadModel()
{
    var repository = new Mock<IProductReadRepository>();
    var handler = new ProjectProductReadModelHandler(repository.Object);

    await handler.Handle(command, CancellationToken.None);

    repository.Verify(x => x.UpsertAsync(
        It.Is<ProductReadModel>(m => m.Id == command.ProductId),
        CancellationToken.None), Times.Once);
}

// Order — verifies idempotent import behavior via notification handler
[Fact]
public async Task Handle_ShouldUpdate_ImportedProduct_WhenAlreadyExists()
{
    dbContext.ImportedProducts.Add(ImportedProduct.Create(productId, "Old Name", 10m, 5, oldDate));
    await dbContext.SaveChangesAsync();

    var handler = new ProductCreatedNotificationHandler(dbContext);
    await handler.Handle(notification, CancellationToken.None);

    var imported = await dbContext.ImportedProducts.SingleAsync();
    Assert.Equal("Starter Basket", imported.Name);
    Assert.Equal(42.50m, imported.Price);
}

The tests use TestContainers to spin up real PostgreSQL, MongoDB, RabbitMQ, and Kafka containers per test collection. The integration tests prove the full flow: HTTP → EF write → outbox drain → MediatR projection → MongoDB. The unit tests prove handler behavior and idempotency without infrastructure.

Running the Sample

Build the solution:

`1`	`dotnet build src/masstransit-transactional-messaging-sample/masstransit-transactional-messaging-sample.slnx`

Run unit tests (fast, no infrastructure needed):

1
2

dotnet test --project src/masstransit-transactional-messaging-sample/tests/Services/Catalog/ECommerce.Services.Catalogs.UnitTests
dotnet test --project src/masstransit-transactional-messaging-sample/tests/Services/Order/ECommerce.Services.Orders.UnitTests

Run integration tests (requires Docker — starts PostgreSQL, MongoDB, RabbitMQ, and Kafka containers):

1
2

dotnet test --project src/masstransit-transactional-messaging-sample/tests/Services/Catalog/ECommerce.Services.Catalogs.IntegrationTests
dotnet test --project src/masstransit-transactional-messaging-sample/tests/Services/Order/ECommerce.Services.Orders.IntegrationTests

Conclusion

Transactional messaging is not about the broker. Whether RabbitMQ or Kafka, the hard problems are the same: keeping writes and message delivery consistent, protecting consumers from duplicates, and handling local side effects without coupling them to the request transaction.

The key is designing the workflow so each piece stays consistent when things fail — outbox in the same DB transaction, idempotent consumers, and a MediatR handler for local work. The sample proves this end to end with integration tests against live containers.

You can find the sample code in this repository:

https://github.com/meysamhadeli/blog-samples/tree/main/src/masstransit-transactional-messaging-sample

Reference

Keycloak JWT Token Revocation: Why Logout Does Not Always Return 401

Mon, 16 Feb 2026 00:00:00 +0000

When a user clicks Log out in a frontend application, it is natural to expect the next API request made with the old access token to return 401 Unauthorized. That expectation is only correct when the API checks the authorization server for the token’s current state.

A signed JWT is normally validated locally. The API checks its signature, issuer, claims, and expiration time. It does not automatically call Keycloak after every request. Therefore, a JWT issued for five minutes can remain usable for those five minutes even after the browser logs out or Keycloak receives a revocation request.

This post demonstrates both behaviors with an Angular, Keycloak, and .NET 10 products catalog:

local JWT validation, which is fast and accepts a valid token until expiration
strict JWT validation with Keycloak introspection, which detects revocation on the next API call

The sample uses Authorization Code Flow with PKCE. The frontend runs on http://localhost:3000, the API on http://localhost:5001, and Keycloak on http://localhost:8080.

The Short Answer

There are three related operations:

Frontend logout clears the application’s local session and redirects the browser.
OIDC logout ends the user’s Keycloak browser session.
Token revocation asks Keycloak to invalidate a token according to its revocation support.

None of these operations edits the JWT already issued to the client. The token still contains the same signed claims and expiration timestamp.

The resource server decides how to validate it:

Local JWT validation:
  verify signature + issuer + claims + exp
  no live Keycloak request

JWT validation + introspection:
  verify JWT locally
  ask Keycloak whether active == true

That is why logout can succeed in the browser while a copied token still works against an API using local JWT validation.

What Is Inside a JWT?

A JWT contains three Base64URL-encoded parts:

`1`	`header.payload.signature`

Its payload might contain:

{
  "iss": "http://localhost:8080/realms/implicit-demo",
  "sub": "user-id",
  "aud": "api-introspection",
  "iat": 1788080000,
  "exp": 1788080300
}

The exp claim is important. The API can prove that Keycloak signed the token and that it has not expired. It cannot discover a later revocation event from the token itself because the token is immutable.

A useful distinction is:

1
2

JWT validation answers: "Was this token correctly issued and is it within its lifetime?"
Introspection answers:   "Does Keycloak currently consider this token active?"

These are different questions.

What Revocation Actually Revokes

Keycloak’s revocation endpoint supports both access tokens and refresh tokens:

`1`	`POST /realms/{realm}/protocol/openid-connect/revoke`

Revoking each token has a different effect:

Access-token revocation marks that token as revoked at Keycloak. An API using local JWT validation still cannot see that change; it can continue accepting the signed JWT until exp.
Refresh-token revocation prevents the client from using that refresh token to obtain another access token. It does not rewrite an access JWT that the client already received.
OIDC logout ends the browser session and asks Keycloak to end the client session. It is not a live invalidation mechanism for APIs that only validate JWTs locally.

Therefore, a complete client logout should discard its local access token and refresh token, revoke the refresh token when the client can do so, and end the OIDC session. A resource server that needs immediate rejection must use introspection, a revocation list, or another server-side policy.

The revocation endpoint normally returns success without exposing whether the submitted token was already valid. Treat the token as unusable after a successful request and never log its value.

Keycloak Configuration

The imported realm configures a five-minute access-token lifetime:

{
  "realm": "implicit-demo",
  "accessTokenLifespan": 300,
  "clients": [
    {
      "clientId": "implicit-client",
      "publicClient": true,
      "standardFlowEnabled": true,
      "implicitFlowEnabled": false
    },
    {
      "clientId": "api-introspection",
      "publicClient": false,
      "serviceAccountsEnabled": true
    }
  ]
}

The Angular client is public because a browser application cannot safely store a client secret. PKCE protects the authorization-code exchange. The backend introspection client is confidential and owns the secret used to call Keycloak.

In Keycloak Admin Console, the useful screens are:

Realm settings -> Tokens: access-token lifespan is five minutes.
Clients -> implicit-client -> Capability config: Standard Flow enabled and Implicit Flow disabled.
Clients -> api-introspection -> Credentials: confidential client secret used by the API.

Make sure the Admin Console is using the implicit-demo realm before opening Clients. The master realm contains Keycloak’s built-in clients and will not show implicit-client or api-introspection. The sample imports both clients from keycloak/realm-export.json into implicit-demo when Keycloak starts.

If implicit-demo exists but the clients are still missing, the database volume may have been initialized before the realm export was added. Realm import is not re-applied to an existing realm; import the file manually or recreate the local Keycloak database volume, then select implicit-demo in the Admin Console.

The imported realm contains these settings:

The sample uses sslRequired: NONE for local development. Production deployments must use HTTPS and secret storage.

The frontend uses Authorization Code Flow with S256 PKCE:

await this.client.init({
  onLoad: 'login-required',
  flow: 'standard',
  pkceMethod: 'S256',
  checkLoginIframe: false,
});

The sample logout method revokes the access token and then ends the browser session:

public async logout(): Promise<void> {
  const token = this.client?.token;
  const settings = this.config.value;

  if (token) {
    const response = await fetch(
      `${settings.keycloakUrl}/realms/${settings.keycloakRealm}` +
      `/protocol/openid-connect/revoke`,
      {
        method: 'POST',
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
        body: new URLSearchParams({
          client_id: settings.keycloakClientId,
          token,
          token_type_hint: 'access_token',
        }),
        keepalive: true,
      });

    if (!response.ok) {
      throw new Error(`Token revocation failed: ${response.status}`);
    }
  }

  await this.client?.logout({ redirectUri: window.location.origin });
}

This sample uses a public Angular client, so it sends client_id without a client secret. It currently revokes the access token explicitly. If the application also keeps a refresh token, revoke that token before clearing it:

curl --location --request POST \
  'http://localhost:8080/realms/implicit-demo/protocol/openid-connect/revoke' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=implicit-client' \
  --data-urlencode 'token=REFRESH_TOKEN' \
  --data-urlencode 'token_type_hint=refresh_token'

For a confidential client such as api-introspection, authenticate the revocation request with that client’s credentials instead of exposing a secret in browser code:

curl --location --request POST \
  'http://localhost:8080/realms/implicit-demo/protocol/openid-connect/revoke' \
  --user 'api-introspection:CLIENT_SECRET' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'token=REFRESH_TOKEN' \
  --data-urlencode 'token_type_hint=refresh_token'

This protects the normal browser session. The browser no longer uses the token, and the Keycloak session ends. It does not force every API to perform a new authorization-server check. A copied token can still be replayed by Postman, a test script, or another process.

Before logout, the Angular home page can call the protected endpoint successfully:

After logout, the Angular application clears its local session and redirects to the Keycloak sign-in page:

Scenario One: Local JWT Validation

This is the default high-throughput design in the sample:

public static void AddJwtAuthentication(this WebApplicationBuilder builder)
{
    builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(options =>
        {
            options.Authority = builder.Configuration["Keycloak:Authority"]
                ?? throw new InvalidOperationException(
                    "Missing configuration 'Keycloak:Authority'.");
            options.RequireHttpsMetadata = false;
            options.TokenValidationParameters.ValidateAudience = false;
        });
}

The API downloads Keycloak’s signing keys and validates JWTs locally. It checks the signature, issuer, lifetime, and configured claims. It does not call the revoke endpoint or introspection for each product request.

The API registers this mode with:

`1`	`builder.AddJwtAuthentication();`

Reproduce the behavior

Sign in to the Angular app as demo with password demo-password.
Open the products page and confirm GET /api/v1/catalogs/products returns 200 OK.
Copy the access token from the browser network request.
Click Log out.
Replay the copied token with Postman or curl.

1
2

curl --location 'http://localhost:5001/api/v1/catalogs/products' \
  --header 'Authorization: Bearer ACCESS_TOKEN'

With local validation, the request can still return the four products while exp has not passed. After the five-minute lifetime ends, the same request returns 401 Unauthorized.

This is expected. The API is verifying the token’s signed facts, not querying Keycloak’s current revocation state.

Scenario Two: Strict Revocation With Introspection

Some systems require a revoked token to stop working immediately. Examples include administration APIs, financial operations, sensitive data access, and security demonstrations.

The strict extension keeps local JWT validation and adds a Keycloak introspection call after it succeeds:

public static void AddJwtAuthenticationWithIntrospection(
    this WebApplicationBuilder builder)
{
    builder.Services.AddHttpClient("keycloak-introspection", client =>
    {
        client.Timeout = TimeSpan.FromSeconds(5);
    });

    builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(options =>
        {
            options.Authority = builder.Configuration["Keycloak:Authority"]
                ?? throw new InvalidOperationException(
                    "Missing configuration 'Keycloak:Authority'.");
            options.RequireHttpsMetadata = false;
            options.TokenValidationParameters.ValidateAudience = false;
            options.Events = new JwtBearerEvents
            {
                OnTokenValidated = ValidateTokenWithKeycloakAsync
            };
        });
}

The event sends the bearer token to:

`1`	`/realms/{realm}/protocol/openid-connect/token/introspect`

Keycloak returns an introspection document. The important field is active:

1
2
3

{
  "active": false
}

The API rejects the request when the token is inactive or revoked:

using var document = JsonDocument.Parse(
    await response.Content.ReadAsStringAsync());

if (!document.RootElement.TryGetProperty("active", out var active) ||
    !active.GetBoolean())
{
    context.Fail("Token is inactive or revoked");
}

A strict host opts into this behavior explicitly:

`1`	`builder.AddJwtAuthenticationWithIntrospection();`

Reproduce immediate rejection

Start the API with the introspection extension instead of the default extension.
Sign in and call the catalog endpoint with the access token.
Confirm the first request returns 200 OK.
Click Log out, which revokes the access token.
Replay the exact same bearer token.

1
2
3

curl --location --include \
  'http://localhost:5001/api/v1/catalogs/products' \
  --header 'Authorization: Bearer ACCESS_TOKEN'

The API validates the JWT locally, then asks Keycloak for current state. Keycloak reports active: false, so ASP.NET Core authentication fails:

`1`	`HTTP/1.1 401 Unauthorized`

The same result is visible when replaying the old token from Postman or curl:

GET http://localhost:5001/api/v1/catalogs/products
Authorization: Bearer ACCESS_TOKEN

HTTP/1.1 401 Unauthorized

The JWT did not change. The second validation step consulted server-side state and rejected it.

sequenceDiagram participant Browser as Angular app participant KC as Keycloak participant API as Products API participant CLI as Postman or curl Browser->>KC: Revoke token and logout KC-->>Browser: Session ended CLI->>API: Replay old bearer token API->>KC: Introspect token KC-->>API: active = false API-->>CLI: 401 Unauthorized

Test With curl

Use curl to send the same bearer token before and after logout:

ACCESS_TOKEN='paste-the-access-token-here'

curl --location --include \
  'http://localhost:5001/api/v1/catalogs/products' \
  --header "Authorization: Bearer ${ACCESS_TOKEN}"

Before logout, both authentication modes return 200 OK. After logout, local JWT validation can still return 200 OK until exp, while strict introspection returns 401 Unauthorized immediately.

Change only the backend registration between runs:

// Local JWT validation.
builder.AddJwtAuthentication();

// JWT validation plus Keycloak introspection.
builder.AddJwtAuthenticationWithIntrospection();

Why Logout Does Not Change a Local JWT Decision

The frontend, Keycloak, and the API are separate participants:

sequenceDiagram participant Browser as Angular browser participant Keycloak participant API as Products API Browser->>Keycloak: Login with code + PKCE Keycloak-->>Browser: Access JWT Browser->>API: GET products + JWT API->>API: Verify signature and exp API-->>Browser: 200 OK Browser->>Keycloak: Revoke token and logout Keycloak-->>Browser: Revoked/session ended Browser->>API: Replay old JWT alt Local JWT validation API->>API: Signature and exp still valid API-->>Browser: 200 OK until exp else Introspection enabled API->>Keycloak: Is token active? Keycloak-->>API: active = false API-->>Browser: 401 Unauthorized end

The browser controls the user interface session. Keycloak controls its session and revocation state. The API controls whether it performs only local validation or also checks current server-side state.

Why Not Introspection Everywhere?

Introspection gives immediate revocation, but it changes the performance and availability profile of the API.

Local validation:

signature verification is fast
no Keycloak round trip for each request
Keycloak is not required for every API call
a revoked token may remain accepted until expiration

Introspection:

revocation is detected on the next request
every authenticated request adds network latency
Keycloak becomes a live dependency of the API
Keycloak outages can affect otherwise valid API requests
the API must protect the confidential introspection secret

IHttpClientFactory manages HTTP handlers and sockets, but it does not cache introspection responses. The strict implementation still makes one Keycloak request per authenticated API request.

For most APIs, short-lived access tokens, refresh-token rotation, and local JWT validation are a good default. Use introspection when immediate revocation is a hard requirement.

Handling 401 in the Frontend

The frontend can react to an API 401 and clear its local session:

1
2
3

if (response.status === 401) {
  await this.keycloak.logout({ redirectUri: window.location.origin });
}

This improves the user experience, but it is not the security control. A caller can bypass Angular and send a bearer token directly to the API. The API must enforce authentication independently.

Security Notes

The sample is intentionally local and uses demo credentials. Production systems should also:

use HTTPS for Angular, the API, and Keycloak
keep confidential client secrets out of browser code
store introspection secrets in a secret manager
validate issuer, audience, signature, lifetime, and required claims
keep access tokens short-lived
rotate refresh tokens and protect refresh-token storage
restrict CORS to known frontend origins
define timeout and outage behavior for Keycloak
never log complete bearer tokens

The sample disables audience validation to keep the demonstration focused. A production API should validate its expected audience explicitly.

Conclusion

A JWT does not receive a live update when a user logs out. It is a signed, self-contained credential with an expiration time. Local JWT validation can therefore continue accepting it until exp, even after the frontend clears its session and Keycloak processes revocation.

Immediate 401 Unauthorized behavior requires an additional server-side check. In this sample:

// Fast default: token is accepted while locally valid.
builder.AddJwtAuthentication();

// Strict mode: revoked token is rejected on the next API call.
builder.AddJwtAuthenticationWithIntrospection();

Choose local JWT validation for the normal scalable path. Choose introspection for APIs where immediate revocation is more important than the extra latency and dependency on Keycloak.

You can find the sample code in this repository:

https://github.com/meysamhadeli/blog-samples/tree/main/src/keycloak-jwt-token-revocation

Aspire on dotnetuniversity

Wolverine: Transactional Messaging with RabbitMQ or Kafka, Inbox, Outbox, and Durable Local Queues

The Problem We Want to Solve

What Wolverine Gives Us

Sample Scenario

Why Durable Local Processing Matters

Solution Structure

System Architecture

Message Flow End to End

1. Catalogs receives product creation request

2. MediatR handler orchestrates the write transaction

External Integration Event with RabbitMQ or Kafka

Durable Inbox in Orders

Internal Durable Command for MongoDB Projection

Integration Tests

Conclusion

You can find the sample code in this repository:

Reference

MassTransit: Transactional Messaging with RabbitMQ or Kafka, Inbox, Outbox, and Reliable Local Processing

The Problem We Want to Solve

What MassTransit Gives Us

Sample Scenario

Why Local Processing Still Matters

Solution Structure

RabbitMQ or Kafka with the Same Application Flow

Integration Tests

Running the Sample

Conclusion

You can find the sample code in this repository:

Reference

Keycloak JWT Token Revocation: Why Logout Does Not Always Return 401

The Short Answer

What Is Inside a JWT?

What Revocation Actually Revokes

Keycloak Configuration

Angular Login and Logout

Scenario One: Local JWT Validation

Reproduce the behavior

Scenario Two: Strict Revocation With Introspection

Reproduce immediate rejection

Test With curl

Why Logout Does Not Change a Local JWT Decision

Why Not Introspection Everywhere?

Handling 401 in the Frontend

Security Notes

Conclusion

You can find the sample code in this repository:

Reference