- service berjalan di environment mana
- dependency mana yang dipanggil
- timeout berapa
- retry aktif atau tidak
- database schema mana yang dipakai
- Kafka topic apa yang dipublish/consume
- feature mana yang enable
- tenant mana memakai rule/catalog tertentu
- observability dikirim ke mana
- security policy apa yang enforce

For a given running pod/process, what exact configuration is active, from which source, with what precedence, and how can we prove it safely?

same artifact + different config = different system behavior

quote.order.timeout.ms=3000
quote.order.retry.maxAttempts=2
quote.order.kafka.topic=quote-order-events-v2
quote.order.db.pool.maxSize=30

- latency
- throughput
- retry amplification
- event compatibility
- database pressure
- incident blast radius

db.password=plain-text-password
lastProcessedOrderId=ORD-123

Configuration should describe desired behavior, not hold confidential material or mutable business state.

Source examples:
- hardcoded default
- Java system property: -Dkey=value
- environment variable
- application.properties
- YAML file
- profile-specific property file
- Kubernetes ConfigMap
- Kubernetes Secret
- mounted file
- Helm values
- GitOps manifest
- cloud parameter store
- cloud app configuration service
- feature flag platform
- database-backed tenant configuration

quote.http.client.timeoutMs

- default code value: 1000
- application.properties: 2000
- application-prod.properties: 3000
- environment variable: 5000
- Kubernetes ConfigMap: 4000
- command line system property: 7000

value final yang dipakai berapa?

1. hardcoded safe default
2. base properties file
3. profile-specific properties file
4. environment variables / mounted files
5. system properties / startup override
6. emergency runtime override / feature flag platform

service berjalan di environment atau mode apa?

request/data/config ini milik tenant siapa?

profile=prod-customerA
profile=prod-customerB

profile=prod
region=ap-southeast-1
tenant=resolved per request or per job context

local
unit-test
integration-test
dev
qa
staging
preprod
prod

region
cloud provider
customer segment
deployment mode
on-prem vs cloud
regulated vs non-regulated environment

prod-aws-us-east-customerA-onprem-like-special-case

app.profile=prod
app.region=us-east-1
app.cloudProvider=aws
app.deploymentMode=cloud

app:
  profile: prod
  region: us-east-1
  cloudProvider: aws
  deploymentMode: cloud

If this value changes, do we need rebuild, redeploy, restart, or just dynamic propagation?

@ApplicationPath("/api")
public class QuoteApplication extends Application {
    @Override
    public Set<Class<?>> getClasses() {
        return Set.of(QuoteResource.class);
    }
}

public class QuoteResourceConfig extends ResourceConfig {
    public QuoteResourceConfig() {
        packages("com.example.quote.api");
        property("jersey.config.server.tracing.type", "OFF");
    }
}

public record QuoteServiceConfig(
    Duration quoteCalculationTimeout,
    int maxLineItems,
    boolean enableExperimentalPricing,
    String kafkaTopic
) {}

String timeout = System.getenv("QUOTE_TIMEOUT_MS");
client.setTimeout(Integer.parseInt(timeout));

public record HttpClientConfig(
    Duration connectTimeout,
    Duration readTimeout,
    int maxConnections,
    boolean retryEnabled
) {
    public HttpClientConfig {
        if (connectTimeout == null || connectTimeout.isNegative() || connectTimeout.isZero()) {
            throw new IllegalArgumentException("connectTimeout must be positive");
        }
        if (readTimeout == null || readTimeout.isNegative() || readTimeout.isZero()) {
            throw new IllegalArgumentException("readTimeout must be positive");
        }
        if (maxConnections <= 0) {
            throw new IllegalArgumentException("maxConnections must be positive");
        }
    }
}

- config has type
- validation is centralized
- startup can fail fast
- tests can construct explicit config
- PR review becomes easier

service starts successfully
first production request reaches code path
missing config causes 500

service refuses to start
deployment fails early
bad config never receives production traffic

public final class ConfigValidator {
    public static void validate(QuoteServiceConfig config) {
        requirePositive(config.maxLineItems(), "maxLineItems");
        requirePresent(config.kafkaTopic(), "kafkaTopic");
        requirePositiveDuration(config.quoteCalculationTimeout(), "quoteCalculationTimeout");
    }

    private static void requirePresent(String value, String name) {
        if (value == null || value.isBlank()) {
            throw new IllegalStateException("Missing required config: " + name);
        }
    }

    private static void requirePositive(int value, String name) {
        if (value <= 0) {
            throw new IllegalStateException("Invalid config: " + name + " must be positive");
        }
    }

    private static void requirePositiveDuration(Duration value, String name) {
        if (value == null || value.isZero() || value.isNegative()) {
            throw new IllegalStateException("Invalid config: " + name + " must be positive");
        }
    }
}

A service should not become ready if required configuration is invalid.

boolean authEnabled = getBoolean("auth.enabled", false);

boolean authEnabled = requireBoolean("auth.enabled");

boolean authEnabled = getBoolean("auth.enabled", true);

Default should reduce blast radius, not maximize convenience.

timeout=5000
url=http://service
flag=true

quote.pricing.http.connectTimeoutMs=500
quote.pricing.http.readTimeoutMs=3000
quote.pricing.http.baseUrl=https://pricing.internal
quote.pricing.feature.enableNewDiscountEngine=false

- namespace by domain/component
- include dependency name
- include unit in name or use typed duration format
- avoid vague names
- avoid overloaded generic keys
- distinguish connect/read/request/idle timeout

quote.timeout=5

5 ms?
5 seconds?
5 minutes?

quote.timeoutMs=5000

quote.timeout=5s

If a config value has a unit, the unit must be unambiguous at the declaration site.

- feature flag
- emergency kill switch
- traffic percentage
- non-critical threshold
- temporary routing override

- DB connection URL
- schema compatibility behavior
- security policy
- object mapper behavior
- Kafka topic name
- tenant isolation mode

- half of instances use old value
- in-flight request sees inconsistent values
- dependency clients are not rebuilt safely
- caches are not invalidated
- observability does not show config version
- rollback is unclear

- version
- audit trail
- owner
- validation
- propagation model
- rollback model
- observability

public QuoteResponse calculate(QuoteRequest request) {
    if (config.flags().newPricing()) {
        // path A
    }

    Money price = pricingEngine.calculate(request, config.pricingRules());

    if (config.flags().newPricing()) {
        // path B
    }
}

public QuoteResponse calculate(QuoteRequest request) {
    QuoteRuntimeConfig snapshot = configProvider.currentSnapshot();

    if (snapshot.flags().newPricing()) {
        // path A
    }

    Money price = pricingEngine.calculate(request, snapshot.pricingRules());

    if (snapshot.flags().newPricing()) {
        // path B
    }
}

Use a stable config snapshot for one business operation.

- app version
- config version/hash
- active profile
- region
- feature flag version
- schema version

- secret values
- credentials
- tenant sensitive settings
- customer-specific pricing rules unless authorized

{
  "appVersion": "1.42.3",
  "profile": "prod",
  "region": "ap-southeast-1",
  "configVersion": "2026-07-10T08:30:00Z-7f3a",
  "runtime": "jaxrs-jersey",
  "status": "UP"
}

Can operators identify which config version a failing pod used?

- pod A has timeout 3s, pod B has timeout 10s
- staging uses Kafka topic v1, prod uses v2
- one region has feature enabled, another not
- local default differs from deployment default
- database migration assumes config that only some pods have

- GitOps desired state
- config hash in logs/metrics
- startup config summary
- environment diff tool
- deployment manifest review
- config conformance test

- environment variables
- ConfigMap mounted as env
- ConfigMap mounted as file
- Secret mounted as env
- Secret mounted as file
- projected volume
- external secrets operator
- Helm values rendered to manifest

Env var changes usually require pod restart.
Mounted files may update, but application may not reload them safely.

- does pod restart on config change?
- is checksum annotation used?
- does app watch mounted file?
- is reload atomic?
- what happens to in-flight requests?

- missing required config
- invalid config value
- malformed URL
- unsupported profile
- invalid tenant config baseline
- incompatible feature flag state

startup validation = deep config validation
readiness = current ability to serve
liveness = process health, not dependency health

pricing.timeout=3000
pricing.retry=true

pricing.http.connectTimeoutMs=500
pricing.http.readTimeoutMs=3000
pricing.http.maxConnections=100
pricing.resilience.retry.maxAttempts=2
pricing.resilience.retry.backoffMs=100
pricing.resilience.circuitBreaker.failureRateThreshold=50
pricing.resilience.circuitBreaker.openStateWaitMs=30000

- is timeout shorter than caller timeout?
- is retry budget bounded?
- does retry only happen for safe/idempotent operations?
- does circuit breaker protect the downstream?
- is fallback safe?

db.pool.maxSize=30
db.pool.minIdle=5
db.pool.connectionTimeoutMs=1000
db.pool.idleTimeoutMs=600000
db.statement.timeoutMs=5000
db.transaction.defaultIsolation=READ_COMMITTED

- pool too large overloads DB
- pool too small causes app queueing
- statement timeout too high holds locks too long
- isolation too strict reduces throughput
- missing transaction timeout causes stuck transactions

quote.events.topic=quote-events-v2
quote.events.producer.acks=all
quote.events.producer.enableIdempotence=true
quote.events.consumer.groupId=quote-order-service
quote.events.consumer.maxPollRecords=100
quote.events.consumer.autoOffsetReset=earliest

- is topic compatible with schema version?
- is group ID stable?
- is max poll size aligned with processing time?
- is auto offset reset appropriate?
- is idempotency enabled where needed?

logging.level.root=INFO
logging.level.com.example.quote=INFO
logging.redaction.enabled=true
telemetry.tracing.enabled=true
telemetry.sampling.ratio=0.1
metrics.highCardinalityLabels.disabled=true

- DEBUG enabled globally in production
- request/response body logging enabled with PII
- trace sampling too low during incident
- high-cardinality labels include quoteId/orderId/customerId

private static final String PRICING_URL = "https://pricing.prod.internal";

- impossible to test safely
- breaks environment parity
- hidden dependency

enableNewFlow=true

- who owns it?
- when is it removed?
- is it tenant-specific?
- what is default?
- is rollback tested?

String topic = get("topic", "default-topic");

System.getenv("...")

1. identify running artifact version
2. identify active profile
3. identify active config version/hash
4. inspect startup config summary
5. compare desired manifest vs running pod env/mounts
6. compare pod A vs pod B
7. check feature flag state
8. check tenant-specific override
9. check cloud parameter/app config version
10. check last deployment/config change timeline

kubectl describe pod <pod>
kubectl exec <pod> -- printenv | sort
kubectl get configmap <name> -o yaml
kubectl get secret <name> -o yaml # do not decode casually in shared logs
kubectl rollout history deployment <name>

public interface ConfigSource {
    Optional<String> get(String key);
}

public final class CompositeConfigSource implements ConfigSource {
    private final List<ConfigSource> sourcesInPriorityOrder;

    public CompositeConfigSource(List<ConfigSource> sourcesInPriorityOrder) {
        this.sourcesInPriorityOrder = List.copyOf(sourcesInPriorityOrder);
    }

    @Override
    public Optional<String> get(String key) {
        for (ConfigSource source : sourcesInPriorityOrder) {
            Optional<String> value = source.get(key);
            if (value.isPresent()) {
                return value;
            }
        }
        return Optional.empty();
    }
}

public final class QuoteConfigFactory {
    private final ConfigSource source;

    public QuoteConfigFactory(ConfigSource source) {
        this.source = source;
    }

    public QuoteServiceConfig load() {
        QuoteServiceConfig config = new QuoteServiceConfig(
            requireDuration("quote.calculation.timeout"),
            requireInt("quote.lineItems.max"),
            requireBoolean("quote.pricing.experimental.enabled"),
            requireString("quote.events.topic")
        );
        ConfigValidator.validate(config);
        return config;
    }

    private String requireString(String key) {
        return source.get(key)
            .filter(value -> !value.isBlank())
            .orElseThrow(() -> new IllegalStateException("Missing required config: " + key));
    }

    private int requireInt(String key) {
        try {
            return Integer.parseInt(requireString(key));
        } catch (NumberFormatException e) {
            throw new IllegalStateException("Invalid integer config: " + key, e);
        }
    }

    private boolean requireBoolean(String key) {
        String value = requireString(key);
        if (value.equalsIgnoreCase("true")) return true;
        if (value.equalsIgnoreCase("false")) return false;
        throw new IllegalStateException("Invalid boolean config: " + key);
    }

    private Duration requireDuration(String key) {
        return Duration.parse(requireString(key));
    }
}

- what is the default?
- is the default safe?
- is the config required?
- what is the unit?
- where is it documented?
- who owns it?
- can it differ per environment?
- can it differ per tenant?
- does it require restart?
- is it secret?
- is it logged safely?
- is it validated at startup?
- what happens if it is missing?
- what happens if it is malformed?
- how is it rolled back?

Repository and code:
- where configuration is loaded
- whether config is typed or raw string based
- whether MicroProfile Config, custom config, Jersey property, or another system is used
- whether `ResourceConfig.property(...)` is used for Jersey-specific behavior
- whether config validation runs at startup
- whether default values exist and where
- whether units are explicit

Runtime and deployment:
- active profile naming convention
- config source order and precedence
- Kubernetes ConfigMap/Secret usage
- Helm/GitOps values source
- whether config change triggers pod restart
- whether config hash is exposed in logs/metrics
- whether environment drift is detectable

Security:
- whether secrets are stored separately from config
- whether config dumps are redacted
- whether secret rotation is documented
- whether emergency overrides are audited

Operations:
- how operators inspect active config safely
- how config changes are reviewed
- how rollback is performed
- how config drift is detected
- how tenant-specific config is governed

code defines possible behavior
configuration selects active behavior
runtime applies behavior
observability proves behavior
governance controls behavior changes

What value should I put here?

Who owns this value?
Where does it come from?
What wins if it conflicts?
How is it validated?
How is it observed?
How is it rolled back?
What is the failure mode if it is wrong?

- config vs secret vs state
- source and precedence
- profile vs tenant
- build-time/deploy-time/runtime/request-time config
- typed configuration
- validation and fail-fast startup
- safe defaults
- runtime reload risk
- config versioning and observability
- drift detection
- Kubernetes config behavior
- PR review for config changes