Scala
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Object-Oriented Scala
-
Section 4: Functional Scala
-
Section 5: Collections in Depth
-
Section 6: Type System
-
Section 7: Concurrency and Ecosystem
-
Section 8: Practical Projects
-
Section 9: Interview Practice
-
Section 10: Data Structures and Algorithms in Scala
-
Section 11: More Practice Exercises
-
Section 12: Advanced Functional Patterns
-
Section 13: More Ecosystem
-
Section 14: Scala Collections Library Deep Dive
-
Section 15: Scala Standard Library Deep Dive
-
Section 16: Akka Ecosystem Deep Dive
-
Section 17: Cats and Cats Effect Deep Dive
-
Section 18: Play Framework Deep Dive
-
Section 19: Apache Spark with Scala Deep Dive
-
Section 20: Scala Build Tools Deep Dive
-
Section 21: Scala 3 Specific Features
-
90: Union and Intersection Types
-
Section 22: Scala Testing Deep Dive
-
Section 23: Functional Domain Modeling
-
Section 24: More Data Structures and Algorithms in Scala
-
Section 25: Scala for Data Engineering
-
Section 26: More Practical Projects
-
Section 27: More Interview and Review
-
Section 28: ZIO Ecosystem Deep Dive
-
Section 29: Scala for Machine Learning
-
Section 30: Scala Microservices Architecture
-
Section 31: Scala Type System Deep Dive
-
Section 32: More Practice and Drills
-
Section 33: Scala Performance Deep Dive
-
Section 34: Scala Ecosystem Tooling
-
Section 35: Scala for Reactive Systems
-
Section 36: More Real-World Case Studies
-
Section 37: Scala for Financial Systems
-
Section 38: Scala GraphQL and gRPC
-
Section 39: More Final Projects
-
Section 40: More Interview and Final Review
-
Section 41: Scala for Streaming Data
-
Section 42: Scala Security Practices
-
Section 43: More Language Deep Dive
-
Section 44: Scala Command-Line Tools
-
Section 45: Scala Documentation and Style
-
Section 46: Scala Dependency Management
-
Section 47: More Practical Backend Patterns
-
Section 48: Scala for Event-Driven Architecture
-
Section 49: More Practice Drills Round 2
-
Section 50: Scala Compiler Deep Dive
-
Section 51: Scala for Web Frontends
-
Section 52: More Data Engineering Practice
-
Section 53: Scala Observability
-
Section 54: More Advanced Practice Projects
-
Section 55: Scala for Legacy Java Integration
-
Section 56: More Testing Practice
-
Section 57: Final Mastery Review
-
Section 58: Scala History and Ecosystem Context
-
Section 59: More Concurrency Patterns
-
Section 60: Scala for Configuration Management
-
Section 61: More Domain Modeling Practice
246: Feature Toggling with Typesafe Config
Imagine we're working on a payment processing service. We've just finished building a new CryptoPaymentGateway, but the business team is nervous. They don't want it live for everyone immediately; they want to be able to flip a switch and turn it on or off without us having to rebuild the JAR and redeploy the entire cluster. This is the classic use case for a feature toggle.
The hard-coded trap
My first instinct—and probably yours too—is to just throw a boolean in there. Let's look at how I started this implementation:
case class PaymentProcessor(gateway: PaymentGateway) {
val cryptoEnabled = false // Just a quick flag for now
def process(amount: Double): Unit = {
if (cryptoEnabled) {
println("Routing to Crypto Gateway...")
} else {
println("Routing to Legacy Gateway...")
}
}
}
This works, but it's useless for our actual goal. If the product manager tells me at 2:00 PM on a Tuesday that we need to enable crypto payments, I have to change the code, commit, wait for CI, and deploy. That's too slow. We need this configuration to live outside the compiled bytecode.
Moving it to the config file
Since we're already using Typesafe Config (the industry standard for Scala), I'll move that flag into src/main/resources/application.conf.
# application.conf
features {
crypto-payments = false
}
Now, let's try to pull that value into the code using ConfigFactory. I'll just grab it right inside the processor:
import com.typesafe.config.ConfigFactory
case class PaymentProcessor() {
val config = ConfigFactory.load()
val cryptoEnabled = config.getBoolean("features.crypto-payments")
def process(amount: Double): Unit = {
if (cryptoEnabled) {
println("Routing to Crypto Gateway...")
} else {
println("Routing to Legacy Gateway...")
}
}
}
I ran this, and it worked. I changed the config file to true, restarted the app, and the output changed. But there's a problem here: ConfigFactory.load() is expensive, and calling it inside a case class means every time I instantiate a processor, I'm potentially hitting the disk or parsing files. Plus, the business logic is now coupled to the config library. That's a smell.
Handling the missing key crash
While testing, I accidentally deleted the crypto-payments line from my config file to see what would happen. The app immediately crashed with a ConfigException.Missing. In a production environment, a missing config key shouldn't bring down the entire payment pipeline.
I need a fallback. Typesafe Config doesn't have a "getOrElse" method directly on the config object in the way Scala Maps do, so I'll wrap this in a dedicated FeatureManager. This keeps the "how we get the value" separate from "what the value is."
import com.typesafe.config.ConfigFactory
import scala.util.Try
object FeatureManager {
private val config = ConfigFactory.load()
def isEnabled(featureName: String): Boolean = {
Try(config.getBoolean(s"features.$featureName")).getOrElse(false)
}
}
Now, if the key is missing, it defaults to false. Safe, predictable, and the PaymentProcessor doesn't even know ConfigFactory exists anymore. It just asks FeatureManager.isEnabled("crypto-payments").
Overriding on the fly
Here is the real magic. We still have to restart the app to pick up changes in application.conf, but Typesafe Config has a built-in hierarchy. System properties override the config file.
I tried running my app with a JVM argument:
scala -Dfeatures.crypto-payments=true -cp . PaymentApp
Without changing a single line of code or editing the application.conf file, the feature turned on. This is huge. If we're using Kubernetes, we can just update an environment variable in the deployment spec, roll the pods, and the feature toggles. No code changes, no rebuilds.
By moving the toggle from a hard-coded constant to a managed config key with a safe fallback, we've turned a deployment risk into a simple configuration change.
📋 Practical Task
Implementing a Dynamic Discount Feature Toggle
You are tasked with adding a "Holiday Discount" feature to an existing e-commerce checkout system. This feature should apply a 20% discount to the total price, but only when the toggle is enabled.
Requirements:
- Create an
application.conffile with afeatures.holiday-discountboolean key. - Implement a
FeatureManagersingleton object that safely retrieves boolean flags from the config, defaulting tofalseif the key is missing. - Create a
CheckoutServiceclass with acalculateTotal(price: Double)method. This method should check theFeatureManagerto decide whether to apply the 20% discount or return the original price. - Verify your implementation by running the application once with the config set to
falseand once by overriding it via a system property (-Dfeatures.holiday-discount=true).
There are no comments for now.