0

As I read more and more regarding actor pattern in stateful service, I am not convinced why Actor pattern is good solution with stateful services.

Most of the use cases talk about single-threaded, state managment of actors with short duration of operation in each actor, best scenarios would be small sized calculation in each actor with big numbers in actors operating in parallel.

In such scenarios, the bottle neck would be write operations from lets say millions of actors to the DB. The argument would be storing the states or small sized outputs from each actor to its own state manager or reliable collections such as reliable dictionaries, but still that is different from true stateful service using database.

I think this confuses use case recommendation of stateful services relying on DB vs. true actor patterns.

It would be great if someone can help me understanding what would be good use case of reliable actors with database in stateful service or please correct me if I am not understanding some aspects of reliable actors correct.

swcraft
  • 2,014
  • 3
  • 22
  • 43
  • What make you think that a stateful service writing to the database will have better performance than the actors writing it? At the end they all will send queries to the database and there is no difference where it comes from! – Diego Mendes Oct 05 '18 at 07:54
  • When you are talking about **stateful service with database** are you talking about **reliable services: stateful service that uses the database** or about **reliable services: stateless service that uses the database**? – Oleg Karasik Oct 05 '18 at 10:25
  • May be my statement above wasn't clear enough. The point of above paragraph is I am not sure if stateful actors architecture with database meets the need in scenarios where actors fit the most. May be I am underestimating the throughput performance of requests to databases how they can handle these read / write requests.. – swcraft Oct 05 '18 at 13:47

0 Answers0