Akka.NET Best Practices
When to Use This Skill
Use this skill when:
- Designing actor communication patterns
- Deciding between EventStream and DistributedPubSub
- Implementing error handling in actors
- Understanding supervision strategies
- Choosing between Props patterns and DependencyResolver
- Designing work distribution across nodes
- Creating testable actor systems that can run with or without cluster infrastructure
- Abstracting over Cluster Sharding for local testing scenarios
Reference Files
1. EventStream vs DistributedPubSub
Critical: EventStream is LOCAL ONLY
Context.System.EventStream is local to a single ActorSystem process. It does NOT work across cluster nodes.
Context.System.EventStream.Subscribe(Self, typeof(PostCreated));
Context.System.EventStream.Publish(new PostCreated(postId, authorId));
When EventStream is appropriate:
- Logging and diagnostics within a single process
- Local event bus for truly single-process applications
- Development/testing scenarios
Use DistributedPubSub for Multi-Node
For events that must reach actors across multiple cluster nodes, use Akka.Cluster.Tools.PublishSubscribe:
using Akka.Cluster.Tools.PublishSubscribe;
public class TimelineUpdatePublisher : ReceiveActor
{
private readonly IActorRef _mediator;
public TimelineUpdatePublisher()
{
_mediator = DistributedPubSub.Get(Context.System).Mediator;
Receive<PublishTimelineUpdate>(msg =>
{
_mediator.Tell(new Publish($"timeline:{msg.UserId}", msg.Update));
});
}
}
Akka.Hosting Configuration for DistributedPubSub
builder.WithDistributedPubSub(role: null);
Topic Design Patterns
| Pattern |
Topic Format |
Use Case |
| Per-user |
timeline:{userId} |
Timeline updates, notifications |
| Per-entity |
post:{postId} |
Post engagement updates |
| Broadcast |
system:announcements |
System-wide notifications |
| Role-based |
workers:rss-poller |
Work distribution |
2. Supervision Strategies
Key Clarification: Supervision is for CHILDREN
A supervision strategy defined on an actor dictates how that actor supervises its children, NOT how the actor itself is supervised.
public class ParentActor : ReceiveActor
{
protected override SupervisorStrategy SupervisorStrategy()
{
return new OneForOneStrategy(
maxNrOfRetries: 10,
withinTimeRange: TimeSpan.FromSeconds(30),
decider: ex => ex switch
{
ArithmeticException => Directive.Resume,
NullReferenceException => Directive.Restart,
ArgumentException => Directive.Stop,
_ => Directive.Escalate
});
}
}
Default Supervision Strategy
The default OneForOneStrategy already includes rate limiting:
- 10 restarts within 1 second = actor is permanently stopped
- This prevents infinite restart loops
You rarely need a custom strategy unless you have specific requirements.
When to Define Custom Supervision
Good reasons:
- Actor throws exceptions indicating irrecoverable state corruption -> Restart
- Actor throws exceptions that should NOT cause restart (expected failures) -> Resume
- Child failures should affect siblings -> Use
AllForOneStrategy
- Need different retry limits than the default
Bad reasons:
- "Just to be safe" - the default is already safe
- Don't understand what the actor does - understand it first
3. Error Handling: Supervision vs Try-Catch
When to Use Try-Catch (Most Cases)
Use try-catch when:
- The failure is expected (network timeout, invalid input, external service down)
- You know exactly why the exception occurred
- You can handle it gracefully (retry, return error response, log and continue)
- Restarting would not help (same error would occur again)
public class RssFeedPollerActor : ReceiveActor
{
public RssFeedPollerActor()
{
ReceiveAsync<PollFeed>(async msg =>
{
try
{
var feed = await _httpClient.GetStringAsync(msg.FeedUrl);
var items = ParseFeed(feed);
}
catch (HttpRequestException ex)
{
_log.Warning("Feed {Url} unavailable: {Error}", msg.FeedUrl, ex.Message);
Context.System.Scheduler.ScheduleTellOnce(
TimeSpan.FromMinutes(5), Self, msg, Self);
}
catch (XmlException ex)
{
_log.Error("Feed {Url} has invalid format: {Error}", msg.FeedUrl, ex.Message);
Sender.Tell(new FeedPollResult.InvalidFormat(msg.FeedUrl));
}
});
}
}
When to Let Supervision Handle It
Let exceptions propagate (trigger supervision) when:
- You have no idea why the exception occurred
- The actor's state might be corrupt
- A restart would help (fresh state, reconnect resources)
- It's a programming error (NullReferenceException, InvalidOperationException from bad logic)
Anti-Pattern: Swallowing Unknown Exceptions
catch (Exception ex)
{
_log.Error(ex, "Error processing work");
}
catch (HttpRequestException ex)
{
_log.Warning("HTTP request failed: {Error}", ex.Message);
Sender.Tell(new WorkResult.TransientFailure());
}
4. Props vs DependencyResolver
When to Use Plain Props
Use Props.Create() when:
- Actor doesn't need
IServiceProvider or IRequiredActor<T>
- All dependencies can be passed via constructor
- Actor is simple and self-contained
public static Props Props(PostId postId, IPostWriteStore store)
=> Akka.Actor.Props.Create(() =>
