Concurrency structures processes so they can make progress at the same time or overlap in time, without requiring them to execute simultaneously. It bridges the gap between programs written as sequential definitions and systems that must handle many independent activities. A concurrent system may run work in parallel across CPUs, but it can also share one CPU through time slicing. section 1.6
Concurrency is a route to scalability: when demand rises, an application can use added CPUs rather than depending only on faster processors. This matters for cloud systems spread across servers and data centers, where performance and stability demands continue to grow. Direct use of threads, locks, or fibers leaves developers managing low-level concerns such as awaiting, interruption, and joining. section 1.1
Parallelism and concurrency are related but different. Parallelism means processes execute simultaneously. Concurrency instead defines processes that can coexist or overlap, so the same design can operate on one CPU, many CPUs, one server, or many servers. Threads may provide parallel execution or time sharing, but thread-based designs scale up rather than directly scaling out across a network. section 1.6
A concurrent design must address more than running several tasks:
- Support changing demand by using additional CPU resources without harming performance. section 1.1
- Avoid coupling processes to a fixed number of threads or servers. section 1.6
- Control the complexity created by shared mutable state, database coordination, RPC, and failure handling as an interactive application grows. section 1.3
Business chat at scale
A chat MVP can begin as an in-memory application, then face millions of simultaneous events as users and integrations grow. A traditional path combines threads and locks, database-backed mutable state, polling for updates, and synchronous RPC. Each added network service increases coordination and makes failure isolation harder. An actor-based path instead uses message passing, immutable event logs, event-driven updates, asynchronous messaging, and nonblocking I/O. section 1.3
The actor model supplies a concurrent abstraction based on sending and receiving messages. It decouples application processes from the underlying number of threads and servers, allowing the same programming model to span local execution and distributed deployment. By avoiding shared mutable state, the model is positioned as a way to handle concurrency while scaling to changing demand. section 1.6 section 1.3
Table 1.1 Differences between the traditional approach and the Akka approach (view table figure)
Compare the traditional and actor-based approaches across scaling, interactive updates, network communication, and failure handling. section 1.3
