El modelo de actores lleva décadas siendo una de las formas más elegantes de manejar concurrencia en sistemas distribuidos. En Scala, Akka ha sido durante años la implementación de referencia. En 2022, Lightbend cambió la licencia de Akka a BSL 1.1, una licencia de negocio que no es open source, y la comunidad respondió con Apache Pekko, un fork con licencia Apache 2.0. En 2026, la decisión de cuál usar ya tiene bastante claridad.
El modelo de actores
Los actores son la unidad básica de computación en este modelo. Cada actor tiene un buzón de mensajes, un estado interno que solo él puede modificar y la capacidad de enviar mensajes a otros actores. La concurrencia se consigue porque los actores procesan mensajes de uno en uno, sin bloqueos explícitos ni locks compartidos.
Carl Hewitt propuso este modelo en los 70 y Erlang lo popularizó en sistemas de telecomunicaciones. Akka lo trajo a la JVM. Si has usado Elixir, el modelo es muy parecido: procesos ligeros que se comunican por mensajes.
Akka Typed: actores con tipos
La versión «clásica» de Akka usaba ActorRef sin parámetros de tipo, así que podías enviar cualquier mensaje a cualquier actor y el error aparecía en runtime. Akka Typed (incluido desde Akka 2.6) corrige esto: cada ActorRef[T] solo acepta mensajes de tipo T.
import org.apache.pekko.actor.typed.*
import org.apache.pekko.actor.typed.scaladsl.*
// Definir el protocolo de mensajes
sealed trait Contador
case class Incrementar(n: Int) extends Contador
case class ObtenerValor(replyTo: ActorRef[Int]) extends Contador
// Definir el comportamiento
def contadorBehavior(valor: Int): Behavior[Contador] =
Behaviors.receiveMessage:
case Incrementar(n) => contadorBehavior(valor + n)
case ObtenerValor(replyTo) =>
replyTo ! valor
Behaviors.same
// Lanzar el sistema
val sistema: ActorSystem[Contador] =
ActorSystem(contadorBehavior(0), "ContadorSistema")
sistema ! Incrementar(5)
sistema ! Incrementar(3)
Fíjate que el código usa el namespace org.apache.pekko en lugar de akka. Esa es la única diferencia de API principal entre Apache Pekko y Akka 2.6.
Apache Pekko: el fork open source
Apache Pekko 1.0 se publicó en julio de 2023, apenas un año después de que Lightbend cambiara la licencia de Akka. El fork es compatible a nivel de API con Akka 2.6, con el único cambio relevante siendo el rename del namespace de akka.* a pekko.*.
La migración de Akka a Pekko es mecánica en la mayoría de casos: cambiar imports y dependencias en el build. Hay un script de migración que automatiza buena parte del proceso. Para proyectos nuevos, Pekko es la opción obvia si necesitas licencia Apache 2.0.
Cuándo usar actores
Los actores son especialmente útiles cuando:
- Tienes estado mutable compartido entre múltiples hilos y quieres evitar locks.
- Construyes sistemas distribuidos donde los nodos se comunican por mensajes.
- Necesitas supervisión de fallos: en Akka/Pekko, los actores padre supervisan a sus hijos y pueden reiniciarlos si fallan.
- El throughput de mensajes es muy alto y necesitas procesamiento asíncrono sin bloqueos.
Para APIs web simples o procesamiento de datos, ZIO o Cats Effect suelen ser más apropiados. Los actores añaden complejidad que solo vale la pena cuando el sistema es genuinamente distribuido o cuando la supervisión de fallos es crítica.
Pekko HTTP y Pekko Streams
El ecosistema de Pekko incluye también Pekko HTTP (para construir APIs REST sobre el modelo de actores) y Pekko Streams (para procesamiento de datos con backpressure). Pekko Streams implementa la especificación Reactive Streams, así que es interoperable con Project Reactor (el mundo Spring) y con Akka Streams.
import org.apache.pekko.actor.typed.ActorSystem
import org.apache.pekko.actor.typed.scaladsl.Behaviors
import org.apache.pekko.http.scaladsl.Http
import org.apache.pekko.http.scaladsl.server.Directives.*
given system: ActorSystem[?] = ActorSystem(Behaviors.empty, "HttpServer")
val ruta =
path("hola") {
get {
complete("Hola desde Pekko HTTP")
}
}
Http().newServerAt("localhost", 8080).bind(ruta)
Akka en proyectos existentes
Si tienes proyectos en producción con Akka 2.6 y licencia comercial de Lightbend, pueden seguir funcionando. Pero para proyectos nuevos, o para migraciones que buscan eliminar dependencias comerciales, Pekko es el camino claro.
La comparativa con el ecosistema de actores en otros lenguajes es inevitable. Elixir con su BEAM sigue siendo la referencia en resiliencia y hot code reload para sistemas distribuidos, pero Pekko tiene la ventaja del ecosistema JVM y la integración con código Java existente.
Imagen: Pexels / Brett Sayles