Scenario
Your company uses feature flags to gradually roll out a new checkout flow. Every request checks the feature flag before deciding which implementation to execute.
The feature flags are stored in a remote service (LaunchDarkly, Unleash, or an internal service). One afternoon, the feature flag service becomes unavailable.
Suddenly:
Checkout latency jumps from 40ms to 900ms
Thread pools begin filling up
Circuit breakers start opening
Checkout success rate drops
No application code was deployed.
📢 Get actionable Java and Spring Boot insights every week, including practical code tips and real-world, use-case-based interview questions, to help you level up your backend skills—join 8100+ subscribers for hand-crafted, no-fluff content.
Founding Member Offer: Lock in founding member price at $50/year (~$4/month) for life. Limited spot left
Testimonials
What actually went wrong?
The checkout service made a synchronous network call to evaluate the feature flag before executing any business logic.
If isEnabled() performs a REST call:
@Service
public class FeatureFlagService {
private final RestTemplate restTemplate;
public boolean isEnabled(String feature, User user) {
return restTemplate.getForObject(
"/flags/{feature}?userId={id}",
Boolean.class,
feature,
user.getId()
);
}
}every checkout request now depends on the feature flag service. If the feature flag service becomes slow:
Checkout -> Feature Flag Service (900ms)every checkout request waits for the response, increasing latency and tying up request threads.
Eventually:
Thread pools become exhausted.
Requests begin timing out.
Circuit breakers open.
Checkout appears unavailable, even though its own business logic is healthy.
The feature flag service has unintentionally become part of the critical request path.
How would you redesign the system so a feature flag outage never impacts checkout?
