Actor systems, a model of computation used in concurrent and distributed systems, are designed to address the complexity of managing state and behaviors across multiple entities in parallel execution environments. A core aspect of their design revolves around the message delivery guarantees they provide. In actor systems, at-most-once delivery is often the default guarantee, meaning that a message sent from one actor to another is delivered at most once, but may be lost due to a variety of reasons and will not be re-delivered.

Technical Explanation:

Actor systems, such as those implemented by Akka, Erlang, or Microsoft Orleans, provide a framework where each actor is a fundamental unit of computation. Actors interact exclusively through message passing, leveraging encapsulation to ensure that interactions are free from the complexities associated with shared memory models. Each actor has its own mailbox (message queue) and execution thread, processing received messages sequentially. The at-most-once delivery semantics mean that once a message is sent to another actor, there is no guarantee that the message will reach its destination—it might get lost due to network issues, actor failures, or system faults.

Reasons for At-Most-Once Delivery Default:

1. Performance and Overhead: Ensuring stronger delivery guarantees such as at-least-once or exactly-once necessitates additional mechanisms like message acknowledgments, retries, and complex state management for deduplication. These add latency and computational overhead affecting system performance.
2. Simplicity in Design: By adopting at-most-once delivery, actor models simplify the design by avoiding intricate recovery and state reconciliation processes required for stronger guarantees. This promotes easier reasoning about system behavior and reduces potential bugs or complexities.
3. Fault Tolerance: Actor systems are often used in environments where failures are anticipated. Adopting a model where the actors can handle intermittent message losses encourages designs that are intrinsically resilient to failures.
4. Scale and Efficiency: In scaled distributed systems where thousands of actors might interact, the coordination cost for stronger delivery guarantees can be prohibitive. At-most-once delivery scales efficiently as it minimizes coordination overhead.

Example Scenario:

Consider a distributed system where actors are deployed across different nodes in a network to process a stream of financial transactions. Each transaction is an independent unit that can be retried by the client in the event of a processing failure. Under at-most-once semantics, an actor can simply process incoming transactions, and if a transaction fails due to a message loss, the original sender (client) can decide to retry the transaction based on its own business logic and observation of outcome (i.e., whether it received a confirmation). This approach offloads the reliability requirements from the system to the end-users, allowing the system to maintain high throughput and lower complexity.

Comparative Table of Delivery Guarantees:

Additional Considerations:

• Design Patterns: Developers can implement patterns like "idempotency" where repeated processing of the same message leads to the same state, or use effectively-once processing semantics through unique message identifiers and state checks.
• Hybrid Approaches: Some actor systems allow customization of message delivery semantics on a per-message or per-actor basis, letting developers choose the right trade-off for specific parts of their application.

In summary, at-most-once delivery in actor systems offers a crucial balance between performance and complexity, tuning systems for responsiveness and simplicity over absolute reliability. Developers leveraging actor systems typically design with the understanding that some messages might be lost and architect their system resilience and state management strategies accordingly.