Engineering With Java: Digest #68
Covering Java & Spring Boot related articles that matters!
👋 Java Devs! Welcome to this week’s addition! I am sure you all are doing awesome!
This week, we cover essential insights on:
Cold Cache Startup in Spring Boot
Async log shipping
OpenTelemetry
CQRS
DataFrames
Java Memory Management
Spring Boot 4 Modularization
📢 Consider becoming a paid subscriber for as low as $2.5/mo (with an annual subscription) and support the work :)
Not convinced? Check out the details of the past work
📝 Articles Of The Week (5)
Cold Cache Startup Behavior in Spring Boot: On a cold start, Spring Boot caches are empty, so the first requests are slow because every lookup hits the database or external service. Caches only fill after real traffic accesses them. This can be mitigated by pre-warming caches, using cache loaders, or configuring providers like Caffeine to reduce duplicate loads during startup.
Optimizing MongoDB Queries in Java Applications: This article highlights improving MongoDB performance in Java by using the right indexes, writing index-friendly queries, limiting returned data with projections, and profiling queries to find bottlenecks. Most gains come from good query design and schema choices, not JVM tuning.
Async Log Shipping With Spring Boot Services: This article shows how asynchronous log shipping in Spring Boot keeps request threads fast by offloading log writing and remote log delivery to background workers. Using async appenders and queues prevents logging I/O from slowing down the application under load.
Spring Boot 4 OpenTelemetry Guide: Metrics, Traces, and Logs Explained: Spring Boot 4 makes integrating OpenTelemetry much easier by providing a dedicated starter (
spring-boot-starter-opentelemetry) that bundles tracing, metrics, and OTLP export support, eliminating the need for manually adding many individual dependencies like in earlier versions. With it, we can export metrics, traces, and logs via OTLP to observability backends, automatically instrument common components (HTTP, JDBC, etc.), and configure exporters and sampling through properties. This simplifies adding full observability to cloud-native Spring Boot apps.The CQRS Pattern: Separating Reads from Writes for Scalable Architectures: The Command Query Responsibility Segregation (CQRS) pattern separates writes (commands) from reads (queries) into different models so each can be optimized and scaled independently. This helps systems with high read‑to‑write ratios or complex business logic, but it adds operational complexity, eventual consistency, and coordination challenges. CQRS works well when read and write demands differ widely, but for many apps, a traditional CRUD design with caching or replicas is simpler and sufficient.
Recently Publish In-house Blogs
▶️ Videos Of The Week (3)
There is a missing tool in your Java data structure toolkit – DataFrames!: This talk introduces data frames as a powerful missing piece in Java’s data-oriented programming toolkit. It contrasts object-oriented and data-oriented approaches, emphasizing immutable data, separation of logic, and simpler reasoning. Data frames—tabular, column-typed structures like database tables—offer higher-level abstractions, better performance optimizations, and improved readability.
Java Memory Management Deep Dive : This video explains Java memory management by walking through a simple example and showing where different elements are stored at runtime. It covers the five main memory areas: method area, heap, stack, PC register, and native method stack. Class metadata and static variables live in the method area, objects and instance variable values are stored in the heap, and local variables plus object references are stored in stack frames per method call. The PC register tracks the next instruction for each thread, while the native method stack is used when JVM calls non-Java (native) methods. Together, these explain how Java organizes memory during program execution.
Spring Boot 4 Modularization Explained: What you need to know : Spring Boot 4 introduces modularized auto-configuration, replacing the old single, monolithic auto-configure JAR with smaller, focused modules. This change can break apps during upgrades—for example, the H2 console no longer works by default because its auto-configuration now lives in a separate dependency. The fix is to add the appropriate starter (e.g., spring-boot-starter-h2-console) instead of relying on raw dependencies. To make migration easier, an auto-configure-classic dependency temporarily restores the old behavior. The update improves clarity and reduces bloat, but requires more explicit dependency choices when migrating from Spring Boot 3.x.
📚 Helpful Resources (5)
25 Real-World Use Case-Based Java/Spring Boot Interview Questions
Everything Bundle (Java + Spring Boot + SQL Interview + Certification)
Thanks for reading this far! Consider becoming a free or paid subscriber and support the work :)
Not convinced? Check out the details of the past work
Really solid curation here. The Spring Boot 4 OpenTelemetry starter is a huge step forward becuase manually wiring up all those observability dependencies was always tedious in production setups. I've seen teams spend days configuring OTLP exporters only to realize they missed JDBC auto-instrumentation, so having it all bundled is gonna save a lot of headaches. One thing though: that automatic instrumentation can add latency if sampling isn't tuned right, so keeping an eye on sampling rates early on makes a big diference.