Spring Boot Interview Question - Fix Magic Number Code Smell /Dynamic Reload
Magic numbers, Code smell, Dynamic Reload, Concepts, Code examples and more
Scenario
You are building a Spring Boot shipping service for an e-commerce platform.
Shipping prices change frequently due to carrier contracts and regional rules.
The goal is to gradually improve the design as new requirements emerge.
This is the initial implementation written to “just make it work”.
It embeds business rules directly into code using numeric literals.
What are the issues with above implementation?
Magic numbers are hiding business meaning.
Rules are not self-documenting. Hard to understand for new developers.
Any change requires redeploy.
Logic will be duplicated elsewhere.
What are some of the Immediate fixes we can do ?
We can replace magic numbers with named constants to make intent explicit.
This improves readability without changing behavior.
What Improved: Readability, Intent is explicit, Easier refactoring.
What Still Hurts: Values are still compile-time, Business cannot change pricing, Redeploy still required.
📢 Get actionable Java/Spring Boot insights every week — from practical code tips to real-world use-case based interview questions.
Join 3500+ subscribers and level up your Spring & backend skills with hand-crafted content — no fluff.
I want to offer an additional 40% discount ($ 18 per year) until January 31st. That’s just $1.5/mo. Unlock all the premium benefits including 35+ real world use cases.
Not convinced? Check out the details of the past work
Enum for Domain Modeling
We should move shipping slabs into an enum, grouping data and behavior.
This models shipping as a domain concept, not just if statements.
What Improved: Encapsulation of logic, Self-documenting code, Easy to test.
What Still Hurts: Code change needed for new slabs, Not business-configurable, Hard to support region-specific pricing.
External Configuration (Spring Boot YAML)
We externalize pricing rules into configuration, allowing business-driven changes.
Spring Boot binds config into POJOs.
What Improved
No code change for pricing updates
Environment-specific tuning
Business-readable rules
What Still Hurts
App restart required
No validation on load
Risk of broken config
How do we implement dynamic reload without needing to code deploy?
1. Immutable Configuration Snapshot
We represent all shipping rules in a single immutable snapshot object.
We should store the snapshot in an AtomicReference for lock-free, atomic swaps.
Every thread:
Sees either the old snapshot or the new one
Never sees partially updated rules
Business Logic Uses Snapshot (No Coupling)
Service code does not care how rules are updated
Reads are cheap and safe
No defensive copying or locking needed
Dynamic Reload
Now we can update the local memory with scheduled job that fetches data from OLTP database and update local memory.
@Scheduled(fixedRate = 30000) // every 30 seconds
public void reloadIfExpired() {
holder.update(newSnapshot);
}2. Using Postgres Updates + Redis + AtomicReference
Admin team, writes to database with new updated rules, which triggers the cache update and writes new rules to redis cache.
redisTemplate.opsForValue().set("shipping:rules", rules, Duration.ofMinutes(5));All Spring Boot instances read from the same Redis key, ensuring consistency.
Additionally to save 2-5 ms roundtrip latency to read from redis, we can keep the rules local memory as we discussed previously.
Redis (shared) ---> fetch rules ---> Immutable Snapshot (local) ---> AtomicReferenceOther approach is Redis Pub/Sub (Real-Time Multi-Instance Reload)
Admin’s update to Postgres also updates Redis cache key.
Publishing side: When rules are updated:
redisTemplate.convertAndSend("shipping:update", "reload");Subscriber side: All instances subscribe:
@RedisListener(topic = "shipping:update")
public void handleUpdateMessage(String message) {
shippingConfigHolder.reloadSnapshot();
}Guarantees: all running Spring Boot instances reload the snapshot immediately, in a thread-safe, atomic way.
📚 Useful Links (5)
35+ Real-World Use Case-Based Java/Spring Boot Interview Questions
Everything Bundle (Java + Spring Boot + SQL Interview + Certification)
Happy Coding 🚀
Suraj
Why not use the Spring Config Server? Where we keep all config in git and with refresh we can update it.
Love the progressive refactoring approach here. The journey from magic numbers to AtomicReference really ilustrates how technical debt accumulates when business logic lives in code. One thing worth adding: the enum stage is often underestimated but it's where domain modeling actually begins, turning procedural logic into behavioral types. The Redis pub/sub pattern for multi-instance relaod is solid, though Aaaa's point about fallback stratgy is crucial in production.