> On Apr 22, 2017, at 9:12 AM, Justin du coeur <[email protected]> wrote: > Personally, I'd likely use Akka Cluster Sharding for this -- assuming each > request can be summarized in a way that fits as an entity identifier, it > seems like a good fit. In this model, the sharded entity would serve as a > read-through cache for the external service: your stream would go to the > sharded Actor -- if it's the first request, the Actor would make the external > request, otherwise it would already know about the value and return it. > Cluster Sharded Actors are a lot like an in-memory cache, and I use them for > exactly this in a number of cases. > > I'd probably only bother with Akka Persistence (I assume you're thinking of > building this on top of Redis) if the number of distinct request types is too > large to typically fit in memory (so the Sharded Actors would need to > sometimes get flushed), and too expensive/slow to want to ever re-run a > request externally. Might be worthwhile, might not; it depends on the > external constraints.
That’s good to hear. I have some experience setting up an Akka Cluster in AWS before, but haven’t used cluster sharding. We might be able to get away without using Akka Persistence - we’re still working out those external constraints. Once “cached” (instantiated), the value should remain valid for quite a while (source data doesn’t change often), and the external lookup would be against another internal/nearby low-latency service anyway. If by distinct request types you mean number of values cached, we’re probably in the tens of millions, or perhaps hundreds of millions in time. It’s only one type of request though, two parameters that will return back a small data structure. We haven’t sized the data structure yet but it is roughly similar to an Address object - a flat structure with a handful of string fields. Since it’s a cluster that new instances can join, is memory effectively unbounded? That’s an actor instance for each value we’d otherwise cache, so tens or hundreds of millions of actor instances. I know akka scales out well but I have not seen much comparing it to the performance of something like Redis. I wonder at what point (if ever) an actor-per-cached-value doesn’t make sense anymore, if ever, compared to an external cache? I wonder if this also impacts what to pick for “state-store-mode”. Thanks again, Curt -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
