event-driven-architecture

What I do

• Design event-driven systems
• Implement message queues and brokers
• Use event sourcing patterns
• Handle asynchronous messaging
• Build event processing pipelines
• Ensure event ordering and delivery

When to use me

When building loosely coupled, scalable systems, microservices, or real-time processing applications.

Core Concepts

Event-Driven Architecture

• Producers emit events
• Consumers react to events
• Decoupled communication
• Temporal coupling eliminated

Event Types

• Domain Events: Business meaningful
• Integration Events: Cross-service communication
• Change Data Capture: Database changes
• System Events: Infrastructure events

Message Patterns

Point-to-Point

• One producer → One consumer
• Queue-based
• Guaranteed processing

Pub/Sub

• One producer → Multiple consumers
• Topic-based
• Event notification

Message Brokers

Apache Kafka

• Distributed event streaming
• High throughput
• Persistence
• Exactly-once semantics
• Use cases: Log aggregation, CDC, Event streaming

RabbitMQ

• Traditional message broker
• Complex routing
• Multiple protocols (AMQP, MQTT, STOMP)
• Use cases: Task queues, RPC

AWS SQS

• Managed queue service
• FIFO queues
• Dead letter queues
• Use cases: Microservices, Batch jobs

NATS

• Lightweight
• Pub/sub, request/reply
• JetStream for persistence

Event Sourcing

Concept

• Store events, not state
• Rebuild state by replaying events
• Complete audit trail
• Time travel debugging

Implementation

// Command
public class PlaceOrderCommand {
    public Guid OrderId;
    public List<OrderItem> Items;
}

// Event
public class OrderPlacedEvent {
    public Guid OrderId;
    public List<OrderItem> Items;
    public DateTime PlacedAt;
}

// Aggregate
public class Order {
    private List<OrderPlacedEvent> _events = new();
    
    public void PlaceOrder(PlaceOrderCommand cmd) {
        // Validate
        // Create event
        var evt = new OrderPlacedEvent(cmd.OrderId, cmd.Items, DateTime.UtcNow);
        _events.Add(evt);
    }
}

Benefits

• Complete history
• Temporal queries
• Event replay
• Audit trail
• Performance

Challenges

• Event schema evolution
• Eventual consistency
• Performance with many events
• CQRS required

CQRS (Command Query Responsibility Segregation)

Pattern

• Separate read and write models
• Different data structures
• Synchronization via events

Implementation

• Commands: Intent to change
• Queries: Read data
• Read models updated via events

Benefits

• Optimized read/write
• Scalability
• Flexibility

Best Practices

• Idempotent consumers
• Handle duplicates
• Order events appropriately
• Use correlation IDs
• Document event schemas (Avro, Protobuf)
• Version events
• Dead letter handling