One Widget REST API, built three times — Spring Boot 4.1.1, Quarkus 3.40.1, and Micronaut 5.2.2 — run in both JVM and GraalVM native mode, with real measured startup time, memory, throughput, artifact size and native build cost. Includes the four real native-image build failures it took to get Micronaut's build working, and the config file that silently got ignored.
A layered-architecture rule, a no-field-injection rule, and a no-cycles rule, all checked against real compiled bytecode in under two seconds with no Spring context anywhere -- plus a real captured violation, and a FreezingArchRule demonstration showing how to turn a rule on against a codebase that already fails it.
A real CQRS split built with no framework at all: a JPA write model, a second H2 database reached only through its own JdbcTemplate, and two interchangeable projection listeners (synchronous and @Async) that make the latency-versus-freshness trade-off measurable instead of theoretical, including a genuine 404 for an order that was just placed successfully.
A 4-module Maven reactor that proves "the core has no Spring dependency" with mvn dependency:tree instead of a promise, tests the business rule with zero Spring context, and hits (then fixes) three real Spring Boot 4 surprises along the way: @DataJpaTest and @WebMvcTest moved to new artifacts and packages, TestRestTemplate stopped auto-configuring itself, and Spring Data JPA's repository scan silently ignores scanBasePackages in a multi-module layout.
The same order/payment/inventory saga built twice against a real Kafka broker -- choreography and orchestration -- with a real compensating transaction and a real duplicate-delivery idempotent-consumer test.
A real dual-write failure, a real embedded Kafka broker, and the Spring Modulith event publication registry acting as a genuine transactional outbox -- including replaying an incomplete publication for real.
Most monolith-vs-microservices articles produce a tidy threshold number that doesn't survive checking the source it's attributed to. This one uses the real, enforced module boundaries from the Spring Modulith companion app to work through an honest cost accounting, what team size actually predicts, and a concrete five-step extraction sequence — ending in a decision procedure instead of a number.
A clean package diagram is a promise, not an enforcement mechanism. This post builds a real 4-module Spring Boot order-fulfillment app, breaks the boundary between two modules on purpose, watches ApplicationModules.verify() fail with a real stack trace, and shows why the fix most people reach for first — routing through the public API instead of the internals — still fails, and why that matters more than the original mistake.
Five real Spring Boot apps, each driven to a genuine OutOfMemoryError under a constrained heap, each with a real .hprof dump read through Eclipse Memory Analyzer's headless batch report generator. Static caches, ThreadLocal, unremoved listeners, classloader leaks, and unbounded queues -- with the real console transcripts and MAT leak-suspect evidence for every one, plus what the JVM's own defaults quietly leave out when the crash happens in a container.
A flag-by-flag reference for running Spring Boot in containers on JDK 25 and JDK 27, measured in real Docker containers: how UseContainerSupport derives CPU count, collector and heap size from the cgroup, why MaxRAMPercentage fails safely while a hardcoded -Xmx gets the container SIGKILLed, the ActiveProcessorCount lie that inflates GC threads, native memory the heap percentage doesn't cover, and what JEP 523 and JEP 534 change by default on JDK 27.