I’ve been thinking a lot about how modern applications handle complexity while remaining responsive and scalable. In my work with distributed systems, I keep returning to event-driven architectures as a solution that balances these demands effectively. Today I want to share a practical approach using Spring Cloud Stream and Apache Kafka—tools that have transformed how I build resilient microservices.

Have you ever considered what happens when services communicate through events rather than direct calls?

Let me show you how to set up a basic event model. We’ll start by defining our shared events in a common module:

public record OrderEvent(
    String orderId,
    String customerId,
    BigDecimal amount,
    Instant timestamp
) {
    public OrderEvent {
        Objects.requireNonNull(orderId);
        Objects.requireNonNull(customerId);
    }
}

Now, creating a message producer becomes straightforward with Spring Cloud Stream’s functional approach:

@Bean
public Supplier<OrderEvent> orderProducer() {
    return () -> {
        // Business logic to create order
        return new OrderEvent("order-123", "customer-456", 
                            new BigDecimal("99.99"), Instant.now());
    };
}

What if we need to process these events reliably across multiple services?

Here’s how simple it is to create a consumer:

@Bean
public Consumer<OrderEvent> processOrder() {
    return event -> {
        log.info("Processing order: {}", event.orderId());
        // Add your business logic here
    };
}

The configuration ties everything together cleanly:

spring:
  cloud:
    stream:
      bindings:
        processOrder-in-0:
          destination: orders
          group: inventory-service

When errors occur—and they will—we need robust handling. Spring Cloud Stream provides excellent retry mechanisms:

spring:
  cloud:
    stream:
      bindings:
        processOrder-in-0:
          consumer:
            max-attempts: 3
            back-off-initial-interval: 1000

But what happens when retries fail? That’s where dead-letter queues come in:

@Bean
public Consumer<Message<OrderEvent>> processWithDlq() {
    return message -> {
        try {
            processOrder(message.getPayload());
        } catch (Exception e) {
            log.error("Processing failed, sending to DLQ", e);
            throw e; // Automatically routes to DLQ
        }
    };
}

Testing is crucial for event-driven systems. Here’s how I approach integration tests:

@SpringBootTest
@EmbeddedKafka
class OrderServiceTest {
    
    @Autowired
    private KafkaTemplate<String, OrderEvent> kafkaTemplate;
    
    @Test
    void shouldProcessOrderEvent() {
        OrderEvent event = new OrderEvent("test-123", "test-customer", 
                                        new BigDecimal("50.00"), Instant.now());
        
        kafkaTemplate.send("orders", event);
        
        // Verify processing logic
    }
}

Monitoring event flows gives me confidence in production. I always set up basic observability:

management:
  endpoints:
    web:
      exposure:
        include: health, metrics, bindings

The beauty of this approach lies in its simplicity and power. Services remain loosely coupled, scaling becomes natural, and the system gains resilience through asynchronous processing.

Have you noticed how event-driven patterns change how we think about data flow?

I’d love to hear about your experiences with event-driven architectures. What challenges have you faced? What successes have you celebrated? Share your thoughts in the comments below, and if this approach resonates with you, please like and share this article with others who might benefit from these patterns.