Filing45 publishes every stock trade disclosed by members of Congress, the fund managers who file 13Fs, and the executive branch — each row linked back to the filing it came from. This post is not a feature tour. It is about the architecture: why the system is shaped the way it is, which constraints did the shaping, and where I got it wrong first. The short version: almost every design decision in this system was forced by the documents, not chosen.

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["

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.

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.

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: