Profiles

Profiles and external config let the same application behave differently across environments.

1. Definition

@Profile enables or disables configuration at the bean level, while externalized configuration controls behavior at the property level. The usual best practice is to vary environments through configuration, not by forking code.

2. Core Concepts

What happens underneath

@Profile enables or disables configuration at the bean level, while externalized configuration controls behavior at the property level. The usual best practice is to vary environments through configuration, not by forking code.

When it is useful

Profiles and external config let the same application behave differently across environments. In interviews, highlight common use cases and the related Spring annotations.

What interviewers ask

Common questions cover Profiles trade-offs, debugging, and production pitfalls.

3. Practical Usage

• Use Profiles when the problem truly calls for it.
• Look at configuration and annotations together because both shape runtime behavior in Spring.
• During debugging always inspect startup logs, the bean graph, and active profiles.
• Prefer small components with clear responsibilities.
• In interviews, mention the production trade-off, not only the annotation name.

4. Code Examples

The following example demonstrates Profiles with real Spring annotations.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Configuration
class ClientConfig {
    @Bean
    @Profile("dev")
    PaymentClient stubPaymentClient() {
        return () -> "stub";
    }

    @Bean
    @Profile("prod")
    PaymentClient realPaymentClient() {
        return () -> "real";
    }
}

interface PaymentClient {
    String call();
}

Use profiles mainly for infrastructure differences, not as business feature flags.

5. Trade-offs

• Convention vs explicit configuration — Spring speeds development through convention, but sometimes explicit control is required for predictable behavior.
• Fast development vs transparency — Less boilerplate is good, but too much framework magic can make debugging harder.
• Abstraction vs control — Higher abstraction accelerates development, but you still need to understand low-level behavior.

6. Common Mistakes

• Memorizing annotations without understanding runtime behavior.
• Changing defaults without understanding the consequences.
• Keeping oversized components with weak boundaries.
• Ignoring logs and diagnostic tooling.
• Not aligning the test strategy with the specific layer.

7. Senior-level Insights

• A senior Spring engineer also looks at which proxy, bean post-processor, or filter is active under the hood.
• Most hard bugs are not about annotation names but about lifecycle and ordering.
• In production thinking, startup time, memory, observability, and rollback strategy all matter.

8. Glossary

• Profiles: A Spring concept or mechanism related to this topic.
• Bean: An object managed by Spring.
• Proxy: An intermediate object that can add behavior.
• Configuration: Properties or bean definitions that shape runtime behavior.
• Context: The current application container state in Spring.

9. Cheatsheet

• Profiles and external config let the same application behave differently across environments.
• Understand the underlying lifecycle.
• In interviews, mention the trade-off, not just the annotation.
• For production bugs, start with logs, bean graph, and active profiles.
• The simplest working solution is often the best one.