32 docs tagged with "protoactor"

An actor is a container for its state, behavior, mailbox, children and supervisor strategy. All of this is encapsulated behind a process ID (PID).

The ask pattern provides request–response semantics between actors. An actor sends a message and waits for a reply, typically by using a future or awaiting a Task.

| Lib | Remote PingPong | Inproc PingPong | SkyNet |

Recommended books for further reading on reactive and actor-based systems.

The CAP theorem states that in the presence of a network partition a distributed system can provide either consistency or availability, but not both simultaneously. For an overview of consistency trade‑offs, see Consistency Models.

In this example, we are going to go beyond Proto.Actor and leverage Proto.Remote package in order to enable bidirectional communication between different actors in a client to server fashion.

A circuit breaker prevents a failing dependency from overwhelming the system. When error rates exceed a threshold the breaker "opens" and short‑circuits requests until the dependency recovers.

Consensus algorithms coordinate state across nodes so that the cluster agrees on a single value. They are essential when strong consistency or coordination is required, as described by the CAP Theorem and the trade‑offs in Consistency Models.

Distributed systems must balance consistency with availability and latency. These choices are often framed by the CAP Theorem. Proto.Actor leaves those trade‑offs to application design so you can choose a model that fits your needs.

Proto.Actor provides two forms of Context, a RootContext and an ActorContext. These contexts are composed of various functionality provided by distinct facets. Both types of context implement Spawner, Stopper, Info and Sender facets, while the ActorContext implements additional facets.

Proto.Actor was born in the Go ecosystem, these design principles was set on day one to conform to the Go mindset.

Proto.Actor helps you build reliable applications which make use of multiple processor

Each actor is the supervisor of its children and defines a fault-handling supervisor strategy.

Actor

To better understand why and when clustering architecture should be adopted, the below subsections show the benefits of actor model in general, its remoting architecture, and its clustering architecture.

In distributed systems messages may be delivered more than once. Idempotent handlers ensure that processing a message multiple times yields the same result, making retries safe.

Virtual Actors with locality to Kafka consumer

The previous section describes how actor PIDs are used to enable location transparency. This special feature deserves some extra explanation, because the related term "transparent remoting" was used quite differently in the context of programming languages, platforms and technologies.

One of the most fundamental concepts to the Actor model is the notion of "message-driven systems," as defined by the Reactive Manifesto:

Actors communicate by exchanging messages. Proto.Actor supports several common patterns that build on this simple foundation.

Intro

This page is part of the Proto.Actor Bootcamp learning path.

Concepts you will learn

TL;DR: Just show me the code!

proto.cluster

scheduling

Service discovery allows nodes to find each other without hardcoded addresses. In dynamic environments like containers or cloud deployments, discovery is essential to keep clusters connected.

Sharding splits data or workload across nodes so that no single machine becomes a bottleneck. In Proto.Actor this typically means distributing virtual actors across the cluster.

This document outlines the concept behind supervision and what that means for your Proto.Actor actors at run-time.

In this chapter we attempt to establish a common terminology to define a solid ground for communicating about concurrent, distributed systems which Proto.Actor targets. Please note that, for many of these terms, there is no single agreed definition. We simply seek to give working definitions that will be used in the scope of the Proto.Actor documentation.

Proto.Actor is a Next generation Actor Model framework.

What features can the Proto.Actor platform offer over the competition?