[t-writescode]

Sure, but that’s almost entirely local within a process, where regular Akka processes would work.

So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues

[halfmatthalfcat]

With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.

[t-writescode]

You can have that with a queueing system, too. As long as you don't ack the message before you're done processing it, the messages that are processing will be sent to the next available client on crash

[halfmatthalfcat]

Sure but the point is it's built into Akka. If you're looking to replace an external queue system, Akka will replace most if not all of it's functionality.

[tunesmith]

What if you have a message that is specifically for another actor that may or may not be on the same server?

[t-writescode]

That doesn't exist in the models I've designed. Microservices still exist and they each do their requisite task, but different work is done by different actors in the actor cluster. Actors are still a fantastic way of handling concurrency, since they can each be treated as single-threaded tiny programs that only think about themselves, and so I've used them in that way.

The actor just won't exist elsewhere, but another microservice that happens to use actors might exist. It would be sent a web request or a message in queue or similar.