Awesome. Really appreciate the insight.
Chris Berthold

Instantiating and querying 40,000 actors is no problem, but hitting the database with 40,000 single SELECT queries to activate those is not cool.

I don’t exactly understand your needs, but I’d encourage you to try and “invert” your thinking even further, when going from using SQL to Actors. Is it possible to maintain the current state (or view) in real time? (again, spreading it over 40,000 actors is no problem) What makes it change? Is it possible to subscribe to those changes, and update every actor that has a copy of the changed data immediately? Oftentimes it is possible to propagate changes using streams or simple actor method calls.

Actors can help avoid database reads by keeping the last state/data in memory, only hitting the database on updates. But this does not work when you update the database without notifying the actor system.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.