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.
A hands-on guide to profiling a live Spring Boot app with Java Flight Recorder: real jcmd and jfr sessions finding a CPU hot method, allocation pressure and lock contention, a custom business event, and four traps that corrupt or hide data — a threshold that silently discards 12ms waits, a shared threshold between concurrent recordings, events lost to a missing try/finally, and a dump/stop bug that doubles every event.
Collections.unmodifiableList, List.of and List.copyOf all refuse direct mutation, but only two of them reject null elements and only one of them is a real snapshot rather than a live view over a list you still hold a mutable reference to. Covers null handling, views vs copies, real JMH construction/read overhead, a brief Guava ImmutableList comparison, and the record field that looks immutable but isn't.