Actors are independent from each other, but transactions might not. How actors are handling situations when they need to communicate between each other?
I have used Akka previously in my career. It is amazing what we can do with it especially cluster sharding and akka streams so you don't have to manage millions of actors , that too with very less resources.
The mailbox is where I'd want an overload contract alongside the resource-usage argument. An actor that receives work faster than it can process it can accumulate latency even when other actors and aggregate CPU look healthy. A useful test would slow one actor's handler, sustain arrivals, and track the age of its oldest queued message. Then verify what happens at the queue limit: reject, defer upstream, or shed explicitly. Cheap actor creation doesn't by itself bound queued work.
Looks like Erlang/Elixir’s OTP model.
or Golang goroutines
That was my first thought as well!
Actor model is rarely used, we use it in Scala in some of our projects. I think its underrated.
good to know, Junaid. Thanks
How many actors were used per virtual machine and what was a single VM resource configuration?
Why are you writing one sentence per paragraph? It’s so annoying to read this article.
I see, thanks for the feedback.
I'll try to improve my writing skills.
Don't listen to him, I think it looks better with the shorter text bodies
Actors are independent from each other, but transactions might not. How actors are handling situations when they need to communicate between each other?
Typically actors do processing and then hand the resulting message off to another actor. It’s just another message, same model.
I have used Akka previously in my career. It is amazing what we can do with it especially cluster sharding and akka streams so you don't have to manage millions of actors , that too with very less resources.
Isn't it kind of same as producer consumer model ?
How many actors were used per virtual machine and what was a single VM resource configuration?
The mailbox is where I'd want an overload contract alongside the resource-usage argument. An actor that receives work faster than it can process it can accumulate latency even when other actors and aggregate CPU look healthy. A useful test would slow one actor's handler, sustain arrivals, and track the age of its oldest queued message. Then verify what happens at the queue limit: reject, defer upstream, or shed explicitly. Cheap actor creation doesn't by itself bound queued work.