The document discusses why actor-based systems are well-suited for microservices architectures. Actor models use message passing for communication between loosely coupled components, avoiding tight coupling issues of HTTP/RPC APIs. Message queues provide lightweight pub/sub messaging that is scalable, available, and promotes eventual consistency over tight synchronization. Actors represent message-driven processes that handle incoming messages asynchronously, supporting natural distributed and concurrent processing. Their built-in failure handling, routing, and back-pressure capabilities make actors a simple and high-level abstraction well-aligned with distributed, message-driven microservices.

1. Technical Overview
[Client]
[Date]
Why Actor-Based Systems Are
The Best For Microservices
Yaroslav Tkachenko
Senior Software Engineer, Lead at Mobify
@sap1ens

3. Monolith Microservices

4. “Easy” way – HTTP / RPC API
POST /foo
service-x.example.com

5. § Destination – where to send request?
§ Service discovery
§ Tight coupling
§ Time – expect reply right away?
§ Failure – always expect success?
§ Retries and failure handling
§ Back-pressure / circuit breakers

6. But wait…
How about Netflix, Twitter, etc.?

7. Yes, it’s possible to build reliable systems
with HTTP/RPC APIs! But:
§ Are you ready to invest a lot of resources
§ Do you really need it?

8. Reactive Revealed: Resiliency, Failures vs Errors, Isolation,
Delegation and Replication by Jonas Boner

9. Surviving Micro-services by Richard Rodger

10. So, let’s try to:
§ Use message queues for communication
§ Use actors as publishers and subscribers

11. - Send …
- Receive …
Another way - Messaging
- Send …
- Receive …
queue.events

12. Enterprise Service Bus?

13. Kafka Connect

14. So, why message queues now?
§ Not ESBs!
§ Lightweight pub/sub instead
§ Low coupling
§ Promotes eventual consistency
§ Highly scalable and available
§ Built-in discovery, retries, tracing, etc.
§ Serverless!

15. By the way, I don’t think that ALL your communication should
happen through the message queues. But it’s something that
you should strive for!

16. External request
(HTTP)

17. External request
(HTTP)Write
Always
asynchronous
using messages
Read
Alternatives to
blocking call:
- Caching
- Denormalization
- Different routing

18. Example: integrations

19. “Macroservices” External APIs

20. “Macroservices” External APIs
New user!

21. “Macroservices” External APIs
New user!
User created

22. EIP was published in 2003 and it contains 65 patterns

23. Enterprise Integration Patterns

24. Patterns from the example:
§ Publish – Subscribe Channel (“Broadcast”)
§ Durable Subscriber
§ Idempotent Receiver

25. So, have I convinced you that messaging patterns are great?

26. But why actors? I can just use a message queue and a bunch
of consumers/producers

27. It’s all about semantics

28. An actor is a computational entity that, in response to a
message it receives, can concurrently:
• send a finite number of messages to other actors
• create a finite number of new actors
• designate the behavior to be used for the next message it
receives.

29. Actors are known for concurrency, but let’s focus on message
passing instead

30. Actors in Scala/Akka and Erlang

31. Actor ActorMessage

32. Actor ActorMessage queue

33. ActiveMQ message listener in Java (just kidding)

34. ActiveMQ message listener in Java (zoom-in)

35. Actor-based (Akka) message listener in Scala + Camel

36. Receiver Handler
onMessage(Message)
???
Receiver ActorSender Actor
Mailbox
Message
VS

37. I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with
messages...
OOP to me means only messaging, local retention and
protection and hiding of state-process, and extreme late-
binding of all things.
Alan Kay, one of the fathers of the idea
of object-oriented programming

38. Actors over message handlers:
• Semantically natural message processing that ”feels right”
• No difference between local and remote communication
• Straightforward state management
• Mailbox, routing and back-pressure
• Built-in failure handling (supervisors)

39. Actors in general:
• Simple and high-level abstraction for distribution,
concurrency and parallelism
• Asynchronous, non-blocking and highly performant
message-driven programming model
• Very lightweight message-driven processes

41. Instead of a summary:
Everything is a trade-off!

42. Questions?
sap1ens.com
@sap1ens