If you're heading into a Scala interview, you're almost guaranteed to get hit with the "Akka vs. ZIO" question. It's the classic architectural showdown: the Actor Model versus Functional Effects. To wrap your head around this, imagine you're running a busy professional kitchen.

In the Akka version of this kitchen, you have a team of specialized chefs (Actors). Each chef owns their own station—the grill chef owns the grill, the pastry chef owns the oven. You don't go into the grill chef's station and move things around; you just hand them a ticket (a Message) that says "Medium-rare steak." The chef manages their own state internally. If the pastry chef accidentally sets a towel on fire and panics, the Head Chef (the Supervisor) decides whether to tell them to calm down and restart or to fire them entirely. It's all about isolated entities communicating via mailboxes.

Now, imagine the ZIO version. Instead of chefs, you have a master Recipe Book (the Effect). A recipe doesn't actually do anything; it's just a description of steps. "Step 1: Get butter from the fridge. Step 2: Melt it. Step 3: Brown the flour." The recipe is a value. It only becomes food when the Kitchen Manager (the ZIO Runtime) decides to execute it. If a recipe requires a specific pan (a Dependency), that's written right into the recipe's requirements. If something goes wrong, the recipe doesn't just "crash"; the error is a first-class part of the recipe's type, so you know exactly what could go wrong before you even turn on the stove.

The Battle of State: Actors vs. Refs

Interviewers love to ask how state is handled. In Akka, state is encapsulated. You have a private variable inside an Actor, and the only way to change it is by sending a message. It's great for distributed systems because the Actor could be on a different server entirely, and your code wouldn't change.

// Akka style: State is hidden inside the Actor
class BankAccount(initialBalance: Int) extends Actor {
  var balance = initialBalance // Internal mutable state

  def receive = {
    case Deposit(amount) => balance += amount
    case Withdraw(amount) => if (balance >= amount) balance -= amount
  }
}


In ZIO, we avoid mutable variables like the plague. Instead, we use Ref. A Ref is a thread-safe, functional wrapper around a piece of state. The key difference is that the Ref itself is passed around as a dependency, and the operations on it are wrapped in the ZIO effect. I personally find this much easier to test because I can inject a mock Ref without spinning up an entire ActorSystem.

// ZIO style: State is managed via a Ref
def withdraw(balanceRef: Ref[Int], amount: Int): ZIO[Any, String, Int] = 
  balanceRef.get.flatMap { current =>
    if (current >= amount) 
      balanceRef.update(_ - amount).as(current - amount)
    else 
      ZIO.fail("Insufficient funds")
  }


Supervision vs. Type-Safe Errors
This is where the "philosophy" part of the interview comes in. Akka follows the "Let it crash" philosophy. You build a supervision hierarchy. If a child actor fails, the parent decides the strategy (Restart, Stop, Resume). It's an imperative, external way of handling failure.

ZIO takes the opposite approach: errors are values. Look at the type signature: ZIO[R, E, A]. The E tells you exactly what can go wrong. You don't "crash" and hope a supervisor catches it; you treat the error as a return value that must be handled or explicitly passed up the chain. I'll be honest: Akka's supervision is powerful for massive, distributed clusters, but for business logic, ZIO's type-safe errors save me from countless 3:00 AM production pages because the compiler forced me to handle the edge cases.

When to actually use which?
If the interviewer asks "which is better," don't take the bait. Neither is "better"—they solve different problems. Akka (and its successor, Pekko) is a beast for distributed computing, clustering, and location transparency. If you're building a massive multiplayer game backend or a real-time trading system across ten data centers, Akka is your tool.

ZIO is a powerhouse for building robust, maintainable, and highly concurrent microservices. If your goal is "correctness," resource safety (like ensuring database connections always close), and a clean dependency graph, ZIO is the winner. Most modern Scala shops are leaning towards the ZIO/Cats-Effect style of functional programming, but Akka is still the backbone of some of the largest systems in the world.

📋 Practical Task

Implement a Purely Functional Circuit Breaker with ZIO

In Akka, a Circuit Breaker is often a built-in pattern to prevent a system from hammering a failing downstream service. Your task is to implement a simplified version of this logic using ZIO to demonstrate your understanding of functional state and error handling.

Requirements:

• Create a CircuitState sealed trait with two states: Closed (requests flow) and Open (requests fail immediately).
• Use a Ref[CircuitState] to track the current state of the breaker.
• Implement a function callService[R, E, A](service: ZIO[R, E, A], stateRef: Ref[CircuitState]) that:
  • Checks the state. If Open, it should immediately return a ZIO.fail with a "Circuit is Open" error.
  • If Closed, it attempts to run the service.
  • If the service fails, it should update the stateRef to Open and then fail.
• Ensure your function signature correctly reflects that it can fail with either the service's error E or your own "Circuit is Open" error.

Hint: You may need to use a common supertype for the errors or a custom ADT to combine the service error and the circuit error.