I’ve been thinking a lot lately about how we manage state in modern applications. The more complex systems become, the more we need a clear, traceable record of every change that occurs. That’s why I decided to explore event sourcing with Spring Boot and Apache Kafka—a powerful combination that brings clarity, scalability, and resilience to data-intensive applications.

Event sourcing flips traditional persistence on its head. Instead of storing just the current state, we capture every change as an immutable event. This creates a complete history, allowing us to reconstruct past states or analyze how data evolved over time. When paired with CQRS (Command Query Responsibility Segregation), it enables optimized, independent scaling for reads and writes.

How does this work in practice? Let’s start with the basics. Every state change becomes an event. These events are stored sequentially, forming an audit trail that’s both durable and replayable.

Here’s a simple event interface to get us started:

public interface DomainEvent {
    UUID getAggregateId();
    Instant getTimestamp();
    String getType();
}

With events defined, we need a way to handle commands that trigger these events. Commands represent intentions to change state. For example, a CreateAccountCommand could lead to an AccountCreatedEvent.

@Service
public class AccountCommandHandler {
    
    @Autowired
    private EventStore eventStore;
    
    public void handle(CreateAccountCommand command) {
        AccountCreatedEvent event = new AccountCreatedEvent(
            command.getAccountId(), 
            command.getInitialBalance(), 
            Instant.now()
        );
        eventStore.append(event);
    }
}

Storing events is one thing, but how do we rebuild current state? By replaying all events for a given aggregate. This might sound slow, but optimizations like snapshots can help.

public class Account {
    private UUID id;
    private BigDecimal balance;
    private List<DomainEvent> changes = new ArrayList<>();
    
    public Account(UUID id, List<DomainEvent> events) {
        this.id = id;
        for (DomainEvent event : events) {
            apply(event);
        }
    }
    
    private void apply(DomainEvent event) {
        if (event instanceof AccountCreatedEvent) {
            this.balance = ((AccountCreatedEvent) event).getInitialBalance();
        }
        // handle other event types
    }
}

Now, where does Kafka fit in? It acts as the event bus, distributing events to various consumers that update read models or trigger other processes. This is where CQRS shines—reads and writes are decoupled.

@Configuration
public class KafkaConfig {
    
    @Bean
    public ProducerFactory<String, DomainEvent> producerFactory() {
        Map<String, Object> config = new HashMap<>();
        config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        config.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        config.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, JsonSerializer.class);
        return new DefaultKafkaProducerFactory<>(config);
    }
    
    @Bean
    public KafkaTemplate<String, DomainEvent> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

On the read side, we consume these events to build specialized views optimized for querying. This separation allows us to use the right database for the right job—perhaps Elasticsearch for searches and PostgreSQL for transactions.

@Component
public class AccountEventListener {
    
    @KafkaListener(topics = "account-events")
    public void consume(DomainEvent event) {
        if (event instanceof AccountCreatedEvent) {
            updateReadModel((AccountCreatedEvent) event);
        }
    }
    
    private void updateReadModel(AccountCreatedEvent event) {
        // Update a materialized view in a read-optimized database
    }
}

But what about consistency? Event sourcing introduces eventual consistency between write and read models. This is a trade-off—we gain scalability and resilience but must design our user experience to handle slight delays.

Testing is another critical area. Since our state is built from events, we can test behavior by verifying the event sequence.

@Test
public void shouldEmitEventsOnAccountCreation() {
    CreateAccountCommand command = new CreateAccountCommand(UUID.randomUUID(), new BigDecimal("100.00"));
    commandHandler.handle(command);
    
    List<DomainEvent> events = eventStore.getEvents(command.getAccountId());
    assertEquals(1, events.size());
    assertTrue(events.get(0) instanceof AccountCreatedEvent);
}

As you can see, event sourcing with Spring Boot and Kafka isn’t just theoretical—it’s a practical approach to building robust, scalable systems. Have you considered how an immutable event log could simplify debugging in your own projects?

This architecture does come with complexity, especially around event evolution and schema changes. But with careful design and tools like Spring Boot and Kafka, the benefits often outweigh the costs.

I hope this guide gives you a solid foundation to start experimenting with event sourcing and CQRS. If you found this useful, feel free to like, share, or comment with your thoughts and experiences. I’d love to hear how you’re applying these patterns in your work!