Distributed systems principles
A distributed system runs logic or stores state across more than one process. Calls can fail independently, messages can arrive late, and different parts can temporarily hold different views of the data.
Isolation, messages, and recovery
Akka follows the Reactive Manifesto and Reactive Principles. Isolated state, asynchronous messages, supervision, and back-pressure help a service remain responsive as load changes or parts fail.
Location transparency lets callers address components without knowing which node hosts them. Sharding spreads independent component instances across nodes. Durable state lets an instance recover after a process failure rather than depending on its original machine.
These mechanisms solve different problems. Adding nodes increases capacity across instances; it does not remove the limit on one instance processing commands sequentially. Replication protects against some failures but introduces delay between copies.
Consistency boundaries
Inside an entity, the owner handles commands one at a time against its current state. This provides a local consistency boundary. Put data that must change atomically within that boundary.
Across entities, views, services, and regions, changes propagate through messages. A projection can therefore lag behind the write it represents. Designing around this eventual consistency avoids requiring a global lock for every operation.
An agentic system adds another source of variation: the model can choose different actions for similar inputs. Durable execution controls progress and recovery, but does not make model decisions deterministic. Evaluate behavior and constrain actions as well as handling infrastructure failure.
Next steps
-
State and read models explains entity consistency.
-
The runtime explains sharding, recovery, and cluster partitions.
-
Events and streaming explains duplicate delivery.
-
Design considerations applies these principles to service design.