Choosing a Java Framework Without the Config Bloat Trap: 5 Patterns That Look Efficient

I've lost count of how many times I've seen a Java project with a pom.xml that's longer than the actual business logic. The framework promised speed. Instead, the team spent two weeks wrestling with bean definitions, property sources, and a classpath that somehow included three different versions of the same library. The config bloat trap is real. It's not just about XML vs annotations—it's about the hidden assumptions that frameworks make. They assume you want auto-scanning, auto-configuration, and a dozen convenience features. But what if your app is small? Or old? Or needs to start in under a second? This article is about five patterns that look efficient on the surface but can quietly balloon your setup time and maintenance burden. We'll talk about what actually works, and what's just bloat in disguise.

Why This Topic Matters Now

The rise of microservices and the config explosion

It sneaks up on you. One day you're deploying a monolith with a single application.properties — manageable, boring, stable. Then someone suggests: "Let's split the billing module into its own service." Great call for scalability. But that one decision multiplies your configuration surface by the number of environments, the number of service instances, and the number of inter-service contracts. I have seen teams go from three config files to sixty-four in under six months. Not because they needed complexity — because the framework's default assumptions about service discovery, circuit breakers, and distributed tracing all demanded config entries. Empty ones. Placeholder values that break at runtime if you forget a single comma.

The real stab comes later: a production incident where the wrong config profile loads — and you spend eight hours debugging something that isn't code. That hurts. Microservices don't cause bloat directly; they amplify the existing tendency of frameworks to demand answers to questions you haven't asked yet. The catch is that most teams adopt a new framework hoping it abstracts away complexity, only to discover it has shifted that complexity into configuration.

Java's reputation for verbosity vs. modern frameworks

Java has a branding problem. Developers who grew up on Rails or Node.js joke about the boilerplate, the getters and setters, the ceremony. Modern frameworks like Spring Boot and Micronaut tried to fix that — auto-configuration, annotation-driven setup, sensible defaults. Great idea in theory. In practice, auto-configuration often means "we'll guess what you need, and you'll spend the afternoon overriding it." I've watched a junior dev add one @EnableCaching annotation, only to discover Spring Boot had silently wired in Redis, set a default cache TTL, and started logging connection failures to a server that didn't exist. The framework meant well. The config bloat was invisible until it failed.

That's the trap: modern frameworks look lean at first glance — a single @SpringBootApplication, a few starter dependencies in your POM, and the sample app runs in seconds. But production is not a sample app. Production means custom logging levels per service, externalized secrets for each cloud region, thread pool tuning, connection pool sizing, and the inevitable "override the default Jackson serializer because the frontend expects snake_case." What seemed concise becomes a sprawling mess of @ConfigurationProperties classes and YAML files that nobody on the team fully understands. "It just works" is a dangerous phrase — it works until it doesn't, and then you don't know why.

Every default configuration is a bet that your context matches the framework author's assumptions. Most production systems lose that bet.

— overheard in an architecture review, post-mortem on a config-triggered outage

What happens when bloat meets production

The most expensive version of config bloat isn't the time spent writing it. It's the debugging, the cross-team misalignment, the slow creep of "let me just add one more property" until you have 400 lines of YAML that nobody dares refactor. Wrong order. Each microservice in a typical deployment needs its own logging config, metrics config, health check config, retry policy config — and those configs must stay in sync across services, or your distributed system behaves like a jigsaw puzzle with missing pieces. I have a friend who spent three days tracing why Service A's readTimeout was 5 seconds while Service B expected 10. Both were Spring Boot. Both used the same library. One had a corporate parent POM that overrode the default, but the override only applied to certain modules. The fix was a single line — finding it took 30 hours of config archaeology.

That sounds like a tooling problem, and partly it's. But the deeper issue is incentive: framework authors optimize for first-run success, not long-term maintainability. Their demos show a clean application.yml with twelve lines. They don't show the cumulative weight of 47 lines of spring.cloud.config overrides, or the three separate places where server.port can be set (environment variable, config server, local file with different precedence). Most teams skip this risk assessment. They pick Spring Boot because it's popular, or Micronaut because it starts fast, without asking the hard question: "What will our config surface look like in two years, across six environments, with half the original team gone?"

You can dodge the worst of this. But not by choosing a framework based on benchmarks or startup time. The patterns that look efficient — auto-configuration, convention over configuration — become traps when you don't understand their boundaries. The next section unpacks what config bloat actually means, byte by byte, so you can recognize it before your production system does.

What Config Bloat Actually Means

Defining bloat: XML, annotations, or magic?

Config bloat is not simply 'too many lines of XML' — though that's the classic boogeyman. I have watched teams rip out 2,000 lines of Spring XML, celebrate with fist bumps, and then quietly accumulate 4,000 lines of annotation-driven code that does the same thing: wires a bean, sets a property, registers a filter. The bloat had just changed shape. Real config bloat is configuration that must be read, understood, and maintained but that doesn't directly express your application's business behavior. An empty cache region definition? Bloat. A JNDI datasource reference that was never actually used in production? Bloat. An interceptor stack that exists only because the framework demanded a default — that's the quiet killer.

The difference between necessary configuration and waste

Not every line of config is waste. That port setting on your embedded Tomcat? Necessary. The ten-line bean definition for a single DataSource that your team copy-pasted because the framework's auto-configuration failed silently? That's waste with a bow on it. The catch is subtle: frameworks often make necessary config invisible, then force you to write redundant config when the magic breaks. I fixed a production issue last year where a Spring Boot app refused to connect to a Postgres replica. The team had spread the connection config across application.yml, an @ConfigurationProperties class, and a custom DataSourceBuilder — three places for one value. That's the trap. You think 'convention over configuration' will protect you, but conventions only cover the happy path. The moment you deviate — oh, you want a read-only replica with a specific isolation level? — you're now writing config that fights the default, and you need to understand both.

Why 'convention over configuration' can backfire

Convention-over-configuration frameworks promise that sensible defaults reduce boilerplate. That sounds fantastic until your convention collides with a real-world constraint. Most teams skip this: they adopt a framework that auto-configures Hibernate, then discover their legacy schema uses composite keys with a custom sequence generator. Suddenly they're overriding three auto-configuration beans, wrestling with @ConditionalOnMissingBean, and debugging why the entity manager factory initializes twice. The convention didn't eliminate config — it just pushed it into the override layer, where it's harder to see and harder to test. One rhetorical question for the room: Would you rather maintain 100 lines of explicit XML that names every dependency, or 30 lines of 'magic' config plus 70 lines of conditionals that you wrote because the magic got the wrong answer?

'Bloat is not a line count. Bloat is the distance between what the config says and what the system actually needs.'

— overheard during a production postmortem, after three engineers spent six hours tracing a missing property that nobody remembered adding to the YAML file

The real problem with 'efficient' patterns is that they often swap one form of bloat for another that's harder to detect. XML bloat is verbose but explicit — you can grep it, schema-validate it, and see every dependency in one file. Annotation bloat is compact but distributed across classes, superclasses, meta-annotations, and conditional logic that fires only when a certain jar is on the classpath. The framework calls that 'convention'. Your team calls it 'why is this filter running in staging but not production?' The most deceptive efficient pattern is the one that hides configuration behind implicit framework behavior, then forces you to understand that behavior before you can fix a single property.

How Frameworks Hide Complexity

Auto-configuration: magic or maintenance nightmare?

Spring Boot's auto-configuration looks like a gift from the framework gods — you add a dependency, and suddenly the app knows how to talk to a database, serve REST endpoints, and serialize JSON. I remember a project where we added spring-boot-starter-web and watched seventeen beans materialize in the context. Seventeen. We hadn't written a single line of infrastructure code. That feels efficient. The catch is that auto-configuration relies on conditional logic — @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty — and each conditional creates a hidden branch in your application's behavior. Change one jar version, and a condition silently flips from true to false. Your datasource pool swaps from HikariCP to Tomcat's default. Connection latencies spike. Most teams skip this: reading the auto-configuration report only after something breaks. By then, you're spending half a day tracing which classpath entry triggered which bean.

Reality check: name the frameworks owner or stop.

The real problem isn't the magic — it's the invisibility. Auto-configuration operates at startup, during the milliseconds before your first request. If a condition fails, you often get a terse NoSuchBeanDefinitionException pointing to a missing dependency you never explicitly declared. That's config bloat masquerading as convenience: bloat in the number of implicit assumptions your framework makes about your environment.

Classpath scanning and its hidden costs

Annotations like @ComponentScan promise zero XML — just point the scanner at a package and let it find your beans. Sounds clean. What usually breaks first is performance under load. Each scan iteration walks the filesystem, loads class metadata, checks annotations, and filters candidates. For a small service with twenty classes, that's irrelevant. For a monolith with four hundred, startup time drifts past thirty seconds. I have seen teams add @ComponentScan at the root package and then wonder why their CI pipeline takes five minutes longer than expected. Wrong order. The scanner rescans every subpackage, including test fixtures, generated sources, and unused libraries.

Even after startup, classpath scanning can hide bloated dependency graphs. The scanner doesn't warn you that a trivial @Service pulls in a transitive dependency on a full ORM. It just loads the bean and moves on. You'll discover the bloat during a memory profile or a container resource quota violation — never during code review. Not yet. That hurts.

The proxy pattern and debugging difficulties

Frameworks wrap your beans in proxies to handle cross-cutting concerns — transactions, caching, security. The proxy intercepts method calls, applies the concern, then delegates to your real implementation. This is elegant until you step through a debugger and see a stack trace that's five frames deeper than any code you wrote. The proxy's name looks com.example.MyService$$EnhancerBySpringCGLIB$$8c3e2a9f. You can't set a breakpoint on it — it's generated bytecode. The transaction boundary that's supposed to roll back? Actually failing inside the proxy's invoke() method, not your service logic. That sounds fine until you're debugging a production incident at 2 AM and every stack frame is a framework artifact.

The trade-off is real: proxies eliminate boilerplate, but they also eliminate transparency. One team I worked with spent six hours debugging a lazy-loading exception that only appeared in a proxied repository — the real class worked fine. The framework hid the seam where the proxy disconnected from the Hibernate session.

Proxies hide the seam between your code and the framework's guarantees — you fix the wrong layer until you learn to look past the wrapper.

— observation from debugging a production transaction rollback issue

From Custom Servlet to Spring Boot: A Migration Walkthrough

The original app: 200 lines of servlet code

I once rescued a five-year-old internal tool that ran on a raw servlet container — no frameworks at all. The whole thing was a single HttpServlet class, roughly 200 lines. It parsed JSON by hand, managed database connections via DriverManager, and handled routing with a chain of if-else blocks on the request URI. Ugly? Yes. But it deployed in under ten seconds, startup logs fit on one screen, and any junior could trace a request end-to-end without opening three XML files. The catch is that 200-line monster did exactly one thing: look up user profiles. Add a second endpoint and the if-else chain doubles. Add authentication and you’re nesting filters like Russian dolls. Still — I have seen teams spend three weeks migrating that same logic into Spring Boot and end up with a six-second startup and 300 lines of configuration that nobody fully understands.

The Spring Boot version: 5 classes and 30 annotations

Our rewrite landed at five Java files plus application.properties. One @RestController, one @Service, one @Repository, a @SpringBootApplication launcher, and a configuration class for the datasource. That looks clean — too clean. The annotations alone total thirty. @Autowired here, @Qualifier there, @Transactional on every save method. What the five-class structure hides is the transitive dependency count: HikariCP, Jackson, Tomcat embedded, Actuator, logging bridges, and three auto-configuration triggers that fire before your code even runs. Most teams skip this: measure the effective line count after Spring Boot expands those annotations at startup. Your 200-line servlet just became 2,000 invisible lines of framework orchestration. That’s not inherently wrong — but it’s a trade-off you can’t evaluate until you’ve felt the pain of debugging why @Value pulled null at 2 AM.

“We spent two days tracing a bean wiring failure. Turned out a profile-specific YAML had a tab instead of spaces.”

— former colleague on a Spring Boot migration, paraphrased

Where the time went: debugging auto-wiring and profiles

Wrong order. That’s what got us. The original servlet connected to the database when the first request hit — simple, deterministic. Spring Boot’s auto-configuration tries to connect during startup, before your datasource bean finishes registering, if a property is missing. We fixed this by adding @ConditionalOnProperty with explicit defaults, but only after three restart cycles and a close look into Spring Boot’s DataSourceAutoConfiguration source code. The profile mess hurt worse. Our staging environment used application-staging.properties — except Spring Boot silently ignores files named after profiles that don’t exist in spring.profiles.active. One typo in the environment variable and the app runs with default H2, not Postgres. That hurts. The servlet version never had that failure mode. It either connected or threw a clear SQLException with the driver’s error message. The hidden cost of Spring Boot’s convenience is the invisibility of failure — errors become silent fallbacks, not hard crashes. I’d still pick Spring Boot for a new project today, but I keep a checklist: spring.autoconfigure.exclude, explicit profiles in @TestPropertySource, and a startup health indicator that checks exactly one thing first. Not the database. Not a remote service. Just: did my required properties load? That one check would have saved us the day.

When Bloat Isn't Bloat: Edge Cases

Multi-module projects and shared configurations

You're staring at a Spring Boot application with forty application-{profile}.yml files, six @ConfigurationProperties classes, and a custom property source that reads from three different secret stores. Looks like bloat, right? I've seen teams rip this apart in a refactor sprint — and then watch builds break for two weeks. The catch is that multi-module projects need a shared configuration layer that feels redundant. Each microservice in a monorepo has its own database connection, its own queue topology, its own circuit breaker thresholds. If you try to hoist all of that into a single common-config module, you create coupling that kills independent deployment. But if you copy-paste config across ten modules? That's not bloat — that's a time bomb.

The real edge case emerges when modules share infrastructure but not behavior. Your Kafka cluster configuration might be identical across services — same brokers, same SSL truststore location — but each service needs different consumer group IDs and retry policies. A shared config module that exposes those as overridable defaults isn't bloat; it's the only sane way to change a broker hostname without touching ten files. We fixed this at a client by keeping a single @ConfigurationProperties prefix per module, with a parent POM that imported a infra-defaults artifact. Fat? Yes. But when the ops team rotated the Kafka certificates, they changed exactly one property file.

Legacy databases with non-standard schemas

Your ORM mapping file is forty lines of JPA annotations for a table that has no primary key, stores dates as VARCHAR(8), and uses a composite foreign key where one column is a checksum. That looks like config bloat — and any framework purist will tell you to normalize the schema. But you can't. The legacy system is still running, still processing payroll, still owned by a business unit that refuses to touch it. What I've learned the hard way: the extra @Column annotations, the custom @TypeDef for the date converter, the @SqlResultSetMapping for that weird cross-join query — none of that's bloat. It's the cost of bridging two design eras without breaking production.

The tricky bit is knowing where to stop. We once added a custom Hibernate interceptor and a Spring @Aspect to handle the same legacy audit column logic. That was bloat — two mechanisms fighting over the same field. The rule I use now: if the configuration exists to map one table or one irregular query, it's probably necessary. If you're writing a generic solution that wraps twenty tables you've never seen — stop. You're inventing a framework on top of a framework, and that's where bloat metastasizes.

“The most expensive configuration is the one you add today for a problem you think you'll have next quarter.”

— overheard at a Java User Group meeting, 2019

Cloud-native deployments with Kubernetes

Here's the scenario that flips the bloat argument on its head: your Spring Boot app runs fine locally with three properties. Push to Kubernetes — and now you need spring.cloud.kubernetes.* config for service discovery, a ConfigMap watcher for hot-reload, readiness and liveness probe endpoints, a @RefreshScope bean for the feature flag that needs live updates, and a custom @ConditionalOnCloudPlatform annotation because some beans should only initialize in the cluster. That's a lot of YAML and Java annotations for what was a main() method and a server.port property. Is it bloat?

Odd bit about frameworks: the dull step fails first.

Not yet. But it becomes bloat the moment you abstract Kubernetes away with a generic cloud-config-starter that your team doesn't understand. I've debugged deployments where a stale ConfigMap watcher kept a pod in CrashLoopBackOff for six hours — because nobody on the team knew the refresh mechanism existed. The edge case here is operational necessity: cloud-native patterns require configuration that looks excessive until you need to roll a canary release at 2 AM. The trick is to annotate clearly, document the startup sequence in a README next to the deployment.yaml, and never let a shared abstraction hide the fact that your app depends on a Kubernetes-native lifecycle. That's not bloat — that's honesty in code.

The Hidden Costs of 'Efficient' Patterns

Startup time vs. developer productivity

Auto-configuration looks like magic on day one — and it's. But magic has a price, and you pay it every time your application boots. Spring Boot's classpath scanning, Hibernate's entity discovery, and Micronaut's annotation processors don't come free. I've watched a simple CRUD service take 38 seconds to start on a developer laptop. That's 38 seconds of context-switching when you change one bean and need to verify behaviour. The team loved how fast they could add a new dependency — just drop it in the classpath and restart. Within a month, that restart had become a coffee break. We had six auto-configured datasources when only one was in use. Honest mistake — someone added a test dependency that pulled in H2, and the framework happily wired it. That's the hidden cost: convenience at compile-time becomes latency at runtime. Worse, those startups accumulate on CI too; a build pipeline with 40 services resets each time you merge. You don't feel it on a single box, but multiply by the team size and the day disappears.

The catch is that some frameworks pitch this as 'developer productivity' while the operations team sees a 200% increase in deployment time. I've seen projects drop Spring Boot for Quarkus or Micronaut specifically to reclaim those seconds. Not because the codebase was wrong — because the pattern itself had a tax that grew with every module. — field observation from a platform engineer at a fin-tech startup

Annotation processing and compilation overhead

Annotations look clean in your IDE. They're not clean under the hood. Each @Autowired, @Transactional, or @RequestMapping triggers a chain of reflection calls, proxy generation, or compile-time weaving. Javac slows down; the annotation processor runs even on unrelated files. We saw compile times climb from 12 seconds to 2 minutes after migrating to a heavy annotation-driven style. That's not hyperbole — we measured it. The team's frustration spiked because every save triggered a rebuild that took longer than the actual coding. Most teams skip this: they attribute slow builds to 'large project size' when it's the annotation processing that's the bottleneck. Run gradle build --scan and look for the annotation processor step. You'll often find it dwarfs actual compilation.

The real pain hits when you need to refactor. Annotations are locked to specific framework versions; upgrade Spring and your @Validated behavior shifts slightly. Suddenly your tests fail not because your logic changed, but because a meta-annotation was updated in a minor release. That's a trap — you can't avoid annotations entirely, but you can push them to the boundary layer instead of scattering them through domain code. We fixed this by using XML for the core wiring and keeping annotations only on the web layer. Unfashionable? Yes. But the build stayed under 30 seconds for two years.

Dependency management and version conflicts

Opinionated frameworks ship with a bill of goods — you get convenience dependencies, but you also inherit their transitive nightmare. Spring Boot's starter POMs pull in Jackson, Hibernate Validator, Logback, and Tomcat by default. What if your project already uses a different JSON library? You either exclude each transitive or accept a dual-classloader headache. I've debugged a week-long mystery where a ClassCastException in serialisation turned out to be two different versions of jackson-core on the classpath. The framework's BOM declared one version; a library declared another. Maven's 'nearest wins' rule picked the wrong one silently.

The breakage is rarely immediate. It surfaces three months later when someone adds a new endpoint and the response suddenly serialises differently. That's the pattern's hidden cost: assumed compatibility across a broad dependency graph. You save time on initial setup but spend it later on conflict resolution. One team I worked with switched to a modular approach — explicit dependencies only, no starters. Their pom.xml grew by 40 lines, but dependency-related incidents dropped to zero over a year. Not every team needs that discipline, but every team should measure whether the 'convenience' of auto-resolution actually saves time net of debugging hours.

— a hard lesson from a production outage that cost eight dev-hours

Reader FAQ: Config Bloat and Framework Choice

Should I use Spring Boot for a 50-line microservice?

You can , but the question is whether you should. I once watched a team spin up a Boot app for a single endpoint that returned a static map — their final JAR was 18 MB with a 4-second startup. That's config bloat wearing different clothes. The framework itself isn't heavy; the transitive dependencies, auto-config scanning, and embedded container all arrive whether you use them or not.

According to field notes from working teams, the boring baseline check prevents more failures than a brand-new framework introduced mid-sprint under pressure.

For a 50-line thing, raw Jakarta EE with a minimal HTTP server or even a plain Java socket handler beats Boot on every metric except developer familiarity. The catch: your next feature might need a database connection pool, and suddenly you're wiring that by hand.

A mentor explained that however polished the dashboard looks, the pitfall is skipping the failure rehearsal that would have caught the silent assumption on day one.

So ask yourself — is this service likely to grow?

Watershed crews keep phenology notes beside the camera-trap cards because absence is a process signal, not a missing checkbox on a template form.

If yes, Boot's overhead pays for itself. If it's a glorified cron job, skip it.

Reality check: name the frameworks owner or stop.

Does Quarkus actually reduce startup time?

Yes — but with a caveat most benchmarks skip.

Not always true here.

Quarkus shifts work from runtime to build time. That first cold start after a `mvn compile`?

It adds up fast.

Fast. Sub-second, usually. What the dashboards don't show is the build itself: GraalVM native-image compilation can take two to four minutes on a modest laptop.

This bit matters.

That hurts during active development. I have seen a team abandon Quarkus purely because their inner loop — edit, compile, test — went from 8 seconds (Spring DevTools) to 90 seconds (Quarkus native rebuild). The trade-off is real. For serverless or container-orchestrated deployments where cold starts matter, Quarkus wins. For a monolith under active iteration, the startup time rarely matters — your app stays up. Measure your actual restart frequency, not just the boot clock.

'We switched to Quarkus for the startup gains, but nobody told us we'd spend an extra 15 minutes every hour waiting for native compiles. That's a cost we didn't model.'

— Senior backend engineer, after a six-month migration

How do I measure config bloat in my project?

Don't count lines of XML or YAML — that's a vanity metric. What usually breaks first is unused configuration surface area. Run `spring-boot-configuration-processor` or Quarkus's `quarkus-maven-plugin:list-extensions` and look for properties you've never touched. Anything that ships with defaults but never gets overridden is potential noise, not bloat — yet. The real signal is boot time regression: compare `spring.application.admin.enabled` on vs off, check how many auto-configuration classes actually match your classpath. A quick test: disable all auto-config classes except the ones your code explicitly needs, then run your test suite. If it passes, you were hauling dead weight. If it breaks, you just found a hidden dependency you didn't know you had. That's bloat — invisible until it bites you at 3 AM during a production incident.

Practical Takeaways

A decision tree for framework selection

Stop reading framework hype and start with two questions. First: will this app talk to a database? If yes, Spring Boot is still the safest bet—not because it's lean, but because its transaction and connection-pool defaults actually work. Second: do you control deployment? If you're packaging a Docker image, Quarkus or Micronaut save you real startup seconds. If you're dropping a WAR into Tomcat, stick with Spring Boot.

The tricky bit is over-selecting. I once watched a team adopt Micronaut for a four-endpoint CRUD service because "it compiles to native." They spent two weeks fighting annotation-processor issues. That's bloat dressed as minimalism. Your decision tree needs a third branch: how many endpoints? Under ten, with no messaging or scheduled jobs? Consider raw Jakarta EE—or even a servlet wrapper. The framework isn't the point. The point is whether you're spending more time in application.yml than in your domain logic.

Checklist: signs your config is bloated

You don't need a linter for this. Look at your project's src/main/resources. If you see more than three YAML files, or any file with over 200 lines, you have a problem. Another tell: every new developer's first pull request touches application.properties. That signal means your config is leaking—it's pulling double duty as documentation, environment mapping, and feature flags.

What usually breaks first is the @ConditionalOnProperty explosion. I once counted twenty-three conditional beans in a project with twelve endpoints. Each one existed because someone didn't want to delete a deprecated property. That hurts. You fix it by asking: does this property change between deploys? If not, hardcode it. If yes, can a default handle 90% of cases? Most teams skip this—they treat config as "flexible" when it's really just dead weight.

Here's a concrete rule: if you can remove a property, restart the app, and nothing breaks, delete it immediately. Not tomorrow. Not after the next release. Now.

'The easiest config to maintain is the one you never wrote. Every unnecessary property is a lie waiting to be discovered.'

— lead engineer, after untangling a team's 600-line properties file that could be replaced by four environment variables

Minimal setup patterns that scale

Start with an empty Spring Boot project—no WebFlux, no Actuator, no DevTools. Add dependencies only when a test forces you. That sounds obvious, but I've seen pom.xml files with sixteen starters for a service that sends emails. The pattern that scales is called defaults-first, override-last: use the framework's auto-configuration until you hit a hard wall, then override exactly one bean at a time. That's it. No custom @Configuration for "readability." No wrapper layers "just in case." Wrong order.

One more tip: write your first integration test before you write any config. Let the failing test drive what you actually need. Most teams configure first and validate later—and end up with twenty properties that nothing depends on. We fixed this by refusing to add a property until a test proved it was necessary. The result? A application.yml file with exactly thirteen lines. It's been two years. It still works.

The next action is specific: open your project now, grep for @ConditionalOnProperty, and remove every one where the default matches the only value you use. That's ten minutes. You'll free up cognitive load you didn't know you were carrying.