The Cluster: Brokers and the Controller A Kafka cluster is a group of servers, each called a broker. Brokers store data and serve producer/consumer requests. One broker in the cluster acts as the controller — it manages partition leadership, handles broker joins and departures, and coordinates rebalancing. In KRaft mode (Kafka 3.3+, the default from Kafka 4.0), the controller is built into Kafka itself — no ZooKeeper needed. flowchart TB subgraph Cluster["
Continue reading »Architecture
4 posts in this section
Building a Modular Monolith with Spring Modulith
Microservices solve organizational and scalability problems — but they add operational complexity. Most applications don’t need that complexity. A modular monolith gives you clean boundaries and loose coupling without the distributed systems overhead. Spring Modulith enforces those boundaries. The Problem with Unstructured Monoliths Without explicit boundaries, every part of the codebase can talk to every other part: // OrderService calling PaymentRepository directly — skipping the Payment module @Service public class OrderService { @Autowired PaymentRepository paymentRepository; // ← wrong @Autowired NotificationService notificationService; // ← wrong @Autowired AnalyticsService analyticsService; // ← wrong } This creates hidden coupling.
Continue reading »Microservices Architecture: When to Split and When Not to
Microservices are not a technology — they’re an organizational strategy. The right reason to split a monolith is team autonomy and independent deployment, not technical elegance. This article covers when splitting makes sense and how to do it without creating a distributed monolith. What Microservices Actually Solve Microservices address two problems: 1. Independent deployment: Team A can deploy the Order Service without coordinating with Team B’s Payment Service. No shared deployment pipeline, no release freeze, no “all-hands” deploy windows.
Continue reading »Spring Modulith: Build a Modular Monolith Before You Commit to Microservices
Microservices solve real problems: independent deployability, team autonomy, technology flexibility. They also create real problems: distributed transactions, network latency, operational complexity. Many teams split into microservices too early, before they understand their domain well enough to draw stable boundaries. Spring Modulith gives you module boundaries, enforced isolation, and event-driven decoupling inside a single deployable JAR. It’s the pragmatic middle ground. The Modular Monolith Problem It Solves A typical Spring Boot monolith looks like this after a year:
Continue reading »