Build fluency in the vocabulary of isolating state behind actors that communicate only via asynchronous messages.
0 / 5 completed
1 / 5
A teammate describes a concurrency design where each unit of state is owned by an isolated entity that only communicates by sending asynchronous messages to other entities' mailboxes, never by sharing memory directly. What is this concurrency model called?
The actor model is exactly this: each actor privately owns its own state and communicates with other actors purely by sending asynchronous messages into their mailboxes, so there is never any directly shared, mutable memory to race over. A DNS zone transfer is an unrelated concept about replicating name server records. This isolate-state-behind-messages approach is exactly why the actor model avoids the locks and shared-memory races that plague traditional thread-based concurrency.
2 / 5
During a system design review, a team picks the actor model for a telecom switching system, specifically because each call session's state lives inside its own actor and mailbox, so no two actors ever touch each other's state directly. Which property does this provide?
The actor model here provides location-transparent, lock-free isolation, since actors never share mutable memory and communicate only via messages, so no actor can corrupt another actor's private state, and actors can even be relocated across machines without changing how other actors address them. A design where every session shares one global mutable struct protected by locks reintroduces exactly the contention and deadlock risk actors were chosen to avoid. This isolate-state-per-actor behavior is exactly why the actor model is favored for systems with many independent, concurrently active sessions.
3 / 5
In a code review, a dev notices a supervisor actor is configured to restart a failing child actor with a fresh mailbox and fresh internal state, rather than letting the crash propagate and take down the whole system. What actor-model concept does this represent?
This is the supervision hierarchy's let-it-crash restart strategy, since a supervisor restarting a failing child in isolation confines the failure instead of letting it propagate and take down the whole system. A cache eviction policy is an unrelated concept about discarded cache entries. This restart-in-isolation pattern is exactly why actor-model systems like Erlang's OTP can keep running even while individual actors repeatedly crash and recover.
4 / 5
An incident report shows a shared mutable counter caused a data race across worker threads, corrupting totals under high concurrency, because multiple threads updated the same memory location without coordination. What actor-model practice would prevent this?
Modeling the counter as its own actor that only updates its private state in response to serialized messages ensures no two updates ever race against each other, since an actor processes one message at a time from its mailbox. Continuing to let every worker thread mutate the same shared counter directly regardless of how many threads are involved is exactly what caused the corruption described in this incident. This one-message-at-a-time approach is the standard fix once shared mutable state is confirmed to be racing under concurrent access.
5 / 5
During a PR review, a teammate asks why the team reaches for the actor model instead of traditional shared-memory threads with locks, given that locks are more familiar to most of the team. What is the reasoning?
The actor model trades a small amount of message-passing overhead for state that is never directly shared and therefore never needs locks, while shared-memory threads with locks are familiar but require careful lock ordering to avoid deadlocks and races as concurrency grows. This is exactly why the actor model is favored for highly concurrent systems with many independent units of state, while simple shared-memory locking remains acceptable for small, tightly scoped critical sections.
What does the "Actor Model Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to actor model vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 9 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.