Event-Driven Architecture

Event-Driven Architecture (EDA) is a design pattern where components communicate by producing and consuming events rather than calling each other directly.

Core Concepts

Concept	Description
Event	A record of something that happened (past tense)
Producer	The component that emits the event
Consumer	The component that reacts to the event
Event Broker	The infrastructure that routes events (Kafka, RabbitMQ, Azure Service Bus)

Producer ──► [ Event Broker ] ──► Consumer A
                              ──► Consumer B
                              ──► Consumer C

Event Types

Domain Event — something meaningful happened in the domain:

public record OrderPlaced(Guid OrderId, Guid CustomerId, decimal Total, DateTime OccurredAt);
public record PaymentReceived(Guid PaymentId, Guid OrderId, decimal Amount);
public record ItemShipped(Guid OrderId, string TrackingNumber);

Integration Event — crosses service boundaries (published to a message broker):

public record UserRegisteredIntegrationEvent(Guid UserId, string Email, DateTime RegisteredAt);

In-Process Events (Domain Events)

Useful within a single application, no broker needed:

// Define a simple dispatcher
public interface IDomainEventDispatcher
{
    Task DispatchAsync<T>(T domainEvent) where T : IDomainEvent;
}

// Raise events inside domain entities
public class Order
{
    private readonly List<IDomainEvent> _events = new();
    public IReadOnlyList<IDomainEvent> DomainEvents => _events;

    public void Place()
    {
        Status = OrderStatus.Placed;
        _events.Add(new OrderPlaced(Id, CustomerId, Total, DateTime.UtcNow));
    }
}

// Dispatch after saving to DB
public class PlaceOrderHandler
{
    public async Task HandleAsync(PlaceOrderCommand cmd)
    {
        var order = new Order(cmd.CustomerId, cmd.Lines);
        order.Place();
        await _repo.SaveAsync(order);

        foreach (var e in order.DomainEvents)
            await _dispatcher.DispatchAsync(e);
    }
}

Out-of-Process Events with RabbitMQ

dotnet add package MassTransit.RabbitMQ

Producer:

public class OrderService
{
    private readonly IPublishEndpoint _bus;

    public OrderService(IPublishEndpoint bus) => _bus = bus;

    public async Task PlaceOrderAsync(PlaceOrderDto dto)
    {
        // ... save order to DB ...
        await _bus.Publish(new OrderPlacedEvent(order.Id, order.CustomerId, order.Total));
    }
}

Consumer:

public class SendConfirmationEmailConsumer : IConsumer<OrderPlacedEvent>
{
    private readonly IEmailService _email;

    public SendConfirmationEmailConsumer(IEmailService email) => _email = email;

    public async Task Consume(ConsumeContext<OrderPlacedEvent> context)
    {
        var e = context.Message;
        await _email.SendOrderConfirmationAsync(e.CustomerId, e.OrderId);
    }
}

Registration:

builder.Services.AddMassTransit(x =>
{
    x.AddConsumer<SendConfirmationEmailConsumer>();
    x.UsingRabbitMq((ctx, cfg) =>
    {
        cfg.Host("rabbitmq://localhost");
        cfg.ConfigureEndpoints(ctx);
    });
});

Azure Service Bus Example

// Send a message
await serviceBusClient.CreateSender("orders").SendMessageAsync(
    new ServiceBusMessage(JsonSerializer.Serialize(new OrderPlacedEvent(order.Id))));

// Receive and process
var processor = serviceBusClient.CreateProcessor("orders");
processor.ProcessMessageAsync += async args =>
{
    var e = JsonSerializer.Deserialize<OrderPlacedEvent>(args.Message.Body);
    await HandleOrderPlaced(e);
    await args.CompleteMessageAsync(args.Message);
};

Outbox Pattern (Guaranteed Delivery)

Prevents events from being lost if the broker is down when the DB transaction commits:

// Save event to outbox table in the same DB transaction
using var tx = await _db.BeginTransactionAsync();
await _db.Orders.AddAsync(order);
await _db.OutboxMessages.AddAsync(new OutboxMessage
{
    Id = Guid.NewGuid(),
    Type = nameof(OrderPlacedEvent),
    Payload = JsonSerializer.Serialize(new OrderPlacedEvent(order.Id)),
    CreatedAt = DateTime.UtcNow
});
await _db.SaveChangesAsync();
await tx.CommitAsync();

// Background worker reads outbox and publishes to broker

EDA vs Request-Response

Aspect	Request-Response	Event-Driven
Coupling	Tight (caller knows callee)	Loose (producer doesn’t know consumers)
Availability	Both sides must be up	Consumer can be down, processes later
Consistency	Synchronous, immediate	Eventually consistent
Complexity	Simple	Higher (broker, error handling, ordering)
Scalability	Limited by callee capacity	Consumers scale independently

When to Use EDA

Good fit for:

• Decoupling microservices
• Workflows that trigger multiple downstream actions
• Audit trails and event sourcing
• Long-running processes (order fulfillment, billing)

Avoid when:

• You need an immediate synchronous response
• Simple CRUD with no downstream side effects
• Team is small and the operational overhead isn’t justified