Understanding Future
A Future[T] represents a computation that may not have completed yet - it is a write-once container that will eventually hold either a successful value of type T or a Throwable if the computation failed. Creating one, Future { expensiveCall() }, requires an implicit ExecutionContext in scope, because the block is scheduled to run asynchronously on a thread pool rather than on the calling thread; unlike a lazy def or Stream, a Future begins executing immediately upon construction (it is eager), so simply creating one already kicks off work in the background.
Cricket analogy: Like placing a bet with a bookmaker on a match result before the toss - the Future is the bet slip, a placeholder that will resolve to a win or loss once the match actually finishes, and it starts 'running' the moment you place it.
Composing Futures
Futures compose with map, flatMap, and for-comprehensions exactly like Option or List, which is what makes asynchronous code readable instead of a pyramid of nested callbacks. userRepo.find(id).flatMap(user => orderRepo.findByUser(user.id)) chains two async calls so the second only starts once the first resolves, and wrapping several independent futures in a single for-comprehension lets you combine their results once all of them complete - but a subtle trap is that if you call Future { ... } separately for two independent tasks before the for-comprehension, they run in parallel because each already started eagerly; only if you construct them lazily inside the for-comprehension do they run sequentially.
Cricket analogy: Like a franchise's scouting pipeline: flatMap on scoutPlayer(id) into checkFitness(player) only evaluates fitness once scouting confirms a player exists - sequential dependency, not two independent checks run at the same time.
import scala.concurrent.{Future, ExecutionContext}
import ExecutionContext.Implicits.global
def findUser(id: Long): Future[User] = userRepo.find(id)
def findOrders(userId: Long): Future[List[Order]] = orderRepo.findByUser(userId)
// Sequential: orders depend on the resolved user
val userWithOrders: Future[(User, List[Order])] = for {
user <- findUser(42L)
orders <- findOrders(user.id)
} yield (user, orders)
// Parallel: both start immediately, independent of each other
val inventoryF = Future { inventoryService.snapshot() }
val pricingF = Future { pricingService.snapshot() }
val combined: Future[(Inventory, Pricing)] = for {
inv <- inventoryF
pr <- pricingF
} yield (inv, pr)Error Handling in Futures
A Future[T] internally resolves to something isomorphic to Try[T] - either Success(value) or Failure(throwable) - and you handle failures with recover (supply a fallback value for specific exceptions, staying in Future), recoverWith (supply a fallback Future for retry-like logic), or by registering onComplete(callback) for side effects like logging. Because a Future is eager, any exception thrown inside the block is caught automatically and stored as a Failure rather than propagating synchronously - this is different from a plain function call, where an uncaught exception would crash the calling thread immediately.
Cricket analogy: Like a third umpire's review that comes back either 'confirmed out' or 'insufficient evidence' - recover lets the on-field umpire fall back to the soft signal instead of the match halting entirely on an inconclusive Future.
ExecutionContext and Thread Pools
Every Future needs an implicit ExecutionContext to run on, and scala.concurrent.ExecutionContext.Implicits.global - a fork-join pool sized to available CPU cores - is the default most projects import. That pool is tuned for CPU-bound, non-blocking work; running blocking calls (JDBC queries, synchronous HTTP clients, Thread.sleep) on it starves other tasks because fork-join threads assume work never blocks. The standard fix is to run blocking code on a separate, bounded ExecutionContext backed by a fixed or cached thread pool, or to wrap the blocking call in scala.concurrent.blocking { ... }, which hints the fork-join pool to temporarily spin up a compensating thread.
Cricket analogy: Like using a T20 specialist bowling attack for quick, sharp overs, but pulling in a separate reserve bowler for a rain-delayed Test match innings that requires long, blocking spells - a dedicated pool for slow, blocking work.
scala.concurrent.blocking { expensiveDbCall() } is a hint, not a guarantee - on the default fork-join ExecutionContext, it signals that the current thread is about to block so the pool can temporarily add a compensating worker thread, reducing but not eliminating starvation. It has no effect on custom ExecutionContexts backed by a fixed ThreadPoolExecutor, since those don't implement the BlockContext compensation protocol.
Await.result(future, timeout) blocks the calling thread until the Future completes or the timeout elapses, defeating the entire purpose of using Future in server code - it should be reserved for the outermost edge of an application (a main method or a test), never inside request-handling logic on a shared thread pool, where it can quickly exhaust available threads under load.
- A Future[T] is an eager, write-once placeholder for a value that may not yet exist, requiring an implicit ExecutionContext to run.
- map, flatMap, and for-comprehensions compose Futures the same way they compose Option and List.
- Futures created before a for-comprehension already run in parallel because they start executing immediately upon construction.
- recover and recoverWith let you supply fallback values or fallback Futures for specific failure cases without leaving the Future context.
- The default global ExecutionContext is a fork-join pool tuned for CPU-bound work and should never run blocking calls directly.
- Blocking calls should run on a separate, bounded ExecutionContext, or be wrapped in scala.concurrent.blocking as a compensation hint.
- Await.result should only appear at the outermost edge of a program, never inside shared request-handling code.
Practice what you learned
1. When does a Future[T] created via Future { ... } begin executing?
2. Why is running a blocking JDBC call directly on the default global ExecutionContext problematic?
3. What does recoverWith allow that recover does not?
4. If two Future { ... } blocks are created as separate vals before being combined in a for-comprehension, how do they execute?
5. What is the purpose of scala.concurrent.blocking { ... }?
Was this page helpful?
You May Also Like
Error Handling with Try and Either
Scala models recoverable failure as ordinary values using Try and Either, letting you compose error-prone code with map, flatMap, and for-comprehensions instead of throwing and catching exceptions.
Scala and Akka Actors
Akka's actor model gives Scala developers a way to build concurrent, distributed systems out of isolated, message-driven actors instead of shared mutable state and locks.
Implicits in Scala
Scala's implicit parameters, implicit conversions, and implicit classes let the compiler thread context and behavior through code automatically, powering type classes and DSLs.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics