I’ve been thinking a lot about how modern applications need to handle thousands of concurrent users while remaining responsive under heavy load. That’s what led me to explore reactive, event-driven architectures—they’re not just buzzwords but essential approaches for building scalable systems.
Let me show you how to build microservices that can handle real-world demands using Spring WebFlux, Apache Kafka, and Redis. Why do these technologies work so well together? They create a foundation where services react to events rather than waiting for direct calls, making everything more resilient and scalable.
Start by setting up your project with the right dependencies. Here’s how your Maven configuration might look:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>
<dependency>
<groupId>io.projectreactor.kafka</groupId>
<artifactId>reactor-kafka</artifactId>
<version>1.3.21</version>
</dependency>
</dependencies>With the setup complete, let’s define our core domain events. These events become the communication backbone between services. How do we ensure different services understand these events? Through a shared contract.
public class OrderCreatedEvent {
private UUID eventId;
private Instant timestamp;
private String orderId;
private String customerId;
private List<OrderItem> items;
public OrderCreatedEvent(String orderId, String customerId, List<OrderItem> items) {
this.eventId = UUID.randomUUID();
this.timestamp = Instant.now();
this.orderId = orderId;
this.customerId = customerId;
this.items = items;
}
}Now, let’s create a reactive Kafka producer that publishes these events without blocking:
@Service
public class EventPublisher {
private final SenderOptions<String, Event> senderOptions;
public EventPublisher(KafkaProperties properties) {
this.senderOptions = SenderOptions.create(properties.buildProducerProperties());
}
public Mono<SenderResult<Void>> publishEvent(Event event) {
return KafkaSender.create(senderOptions)
.send(Mono.just(SenderRecord.create(
"orders-topic",
null,
System.currentTimeMillis(),
event.getAggregateId(),
event,
null
)))
.next();
}
}On the consumer side, we process these events reactively. What happens when messages arrive faster than we can process them? Reactive streams handle backpressure automatically.
@Service
public class OrderEventConsumer {
private final ReceiverOptions<String, Event> receiverOptions;
public OrderEventConsumer(KafkaProperties properties) {
this.receiverOptions = ReceiverOptions.create(properties.buildConsumerProperties());
}
public Flux<Event> consumeEvents() {
return KafkaReceiver.create(receiverOptions)
.receive()
.map(ReceiverRecord::value)
.doOnNext(this::processEvent);
}
private void processEvent(Event event) {
if (event instanceof OrderCreatedEvent) {
handleOrderCreated((OrderCreatedEvent) event);
}
}
}Integrate Redis for reactive caching to reduce database load. Notice how we use reactive types throughout:
@Service
public class OrderService {
private final ReactiveRedisTemplate<String, Order> redisTemplate;
private final OrderRepository orderRepository;
public OrderService(ReactiveRedisTemplate<String, Order> redisTemplate,
OrderRepository orderRepository) {
this.redisTemplate = redisTemplate;
this.orderRepository = orderRepository;
}
public Mono<Order> getOrder(String orderId) {
return redisTemplate.opsForValue().get(orderId)
.switchIfEmpty(
orderRepository.findById(orderId)
.flatMap(order ->
redisTemplate.opsForValue()
.set(orderId, order, Duration.ofMinutes(10))
.thenReturn(order)
)
);
}
}Building reactive REST endpoints with WebFlux feels natural. The non-blocking nature means your service can handle more concurrent requests with fewer resources.
@RestController
@RequestMapping("/orders")
public class OrderController {
private final OrderService orderService;
private final EventPublisher eventPublisher;
public OrderController(OrderService orderService, EventPublisher eventPublisher) {
this.orderService = orderService;
this.eventPublisher = eventPublisher;
}
@PostMapping
public Mono<ResponseEntity<Order>> createOrder(@RequestBody OrderRequest request) {
return orderService.createOrder(request)
.flatMap(order ->
eventPublisher.publishEvent(new OrderCreatedEvent(
order.getId(),
order.getCustomerId(),
order.getItems()
)).thenReturn(order)
)
.map(order -> ResponseEntity.created(URI.create("/orders/" + order.getId())).body(order));
}
}Testing is crucial. Here’s how you might test your reactive components:
@Test
void shouldPublishEventWhenOrderCreated() {
OrderRequest request = new OrderRequest("customer-1", List.of(
new OrderItem("product-1", 2, new BigDecimal("29.99"))
));
webTestClient.post()
.uri("/orders")
.bodyValue(request)
.exchange()
.expectStatus().isCreated()
.expectBody(Order.class)
.value(order -> assertNotNull(order.getId()));
}When deploying to production, consider how you’ll monitor these reactive streams. Tools like Micrometer and Reactor’s metrics help track performance and identify bottlenecks.
Error handling in reactive streams requires careful consideration. Use Reactor’s error handling operators to build resilient services:
public Flux<Event> consumeWithRetry() {
return KafkaReceiver.create(receiverOptions)
.receive()
.map(ReceiverRecord::value)
.onErrorResume(error -> {
log.error("Processing error", error);
return Mono.empty();
})
.retryWhen(Retry.backoff(3, Duration.ofSeconds(1)));
}This approach to building microservices creates systems that scale efficiently while remaining responsive under pressure. The event-driven nature makes services loosely coupled, and the reactive foundation ensures optimal resource utilization.
What questions do you have about implementing this in your own projects? I’d love to hear about your experiences—feel free to share your thoughts or challenges in the comments below. If you found this helpful, please consider sharing it with others who might benefit from these concepts.
