Patterns and anti-patterns in building Akka systems

"Let it crash" Principle

• Recovery should be automatic to restore normal service as soon as possible

Inverted control flow

• Better to push jobs than to pull them
• Reduce the frequency of blocking requests
• Fit nicely with short jobs that comes at a fixed rate
• Not an adequate pattern when
• jobs are produced faster than finished
• jobs are expensive and should be avoided if possible
• Solution: push jobs after old jobs are finished
• Eg. push with rate limit / acknowledgement

Durable mailbox

• Actor system doesn't guarantee the delivery of messages per se
• Have to use additional protocols to approach this purpose
• ack everywhere
• store to persist
• Asking for guarantees in an uncertain world takes costs
• increased effort / complexity / latency
• additional dependency in the architecture

Event sourcing

• A good way to compile a list of time-series events
• Has to take care of replication inconsistency, application latency, etc

Non-blocking request

• Future-based messaging

Sentinel

• handling failure above a supervisor, flow control and distributed workers