Hi everyone, My company is planning to use Akka for a new feature that we're working on and we want to run our design by a few set of eyes from the Akka community just to make sure that what we're doing makes sense and also to get some feedback and see if perhaps there are other ways of doing things.
The new service that we're building will involve accessing 3 different Redis databases to both persist and retrieve data. We can call these 3 databases: TopicDB - holds "topics" that are added/removed. StatusDB - holds the current status of a topic. Every topic is added to this db for tracking its status. Topics are added/updated but never removed. RequestDB - holds a "request" queue. Every topic generates a request in this db, that can also be removed. Basically additions or removals to the TopicDB are driven by an external application which must then direct the updates to the other 2 dbs as appropriate. We're planning on having a setup such that for each db there will be what we call a RedisSyncActor which, as the name implies, will sync up with the particular database that it corresponds to. In order to do this syncing, each of these RedisSyncActors will have at most 2 children, a RedisPersisterActor and a RedisListenerActor which will persist data into Redis and will receive data from Redis respectively. <https://lh4.googleusercontent.com/-coQA-XEkgJw/U9kTQiTcPMI/AAAAAAAAAI4/jB4mhcMNehw/s1600/image1.png> Now, earlier I said at most because in reality, every Redis database will not necessarily make use of both of each children. Based on our requirements, the setup will look like this where the RequestDB is the only one with both a RedisPersisterActor and a RedisListenerActor while the TopicDB only has a RedisListenerActor and the StatusDB only has a RedisPersisterActor. <https://lh3.googleusercontent.com/-AyDu7Pf7w1Q/U9kTWDp9BBI/AAAAAAAAAJA/s7aIYLgDmco/s1600/image2.png> Now, in terms of the data flow and interactions between the actors, this will look something like this: <https://lh5.googleusercontent.com/-eIJNHIc3EEs/U9kTaxgILsI/AAAAAAAAAJI/50Z1o6ABHgs/s1600/image3.png> 1. Whenever the TopicDB is changed by adding or removing what we call "topics", the TopicRedisListenerActor will pick up on these changes by using the pub/sub feature that Redis provides. 2. Once the TopicRedisListenerActor receives these changes it will send them in 2 directions: a. Regardless of what type of topic change it received (ie. a topic that was added, a topic that was removed, etc), the TopicRedisListenerActor will send it back to its TopicRedisSyncActor parent who will in turn send it off to the StatusRedisSyncActor that handles the StatusDB. This StatusRedisSyncActor will then forward the topic changes to its StatusRedisPersisterActor child so that the change can be persisted to the StatusDB. b. Secondly, if the topic change indicates that a topic was removed from the TopicDB, the TopicRedisListenerActor will send a "RemoveTopic" message to the TopicRedisSyncActor. This TopicRedisSyncActor will then forward the change to the RequestRedisSyncActor so that the RequestDB can remove the topic as well. 3. Depending on whether or not StatusDB already knows about the id of the topic changes that it receives, this will cause particular updates to happen in the database. If the topic change reflected the creation of a new topic, then a new entry will be added to the StatusDB and the StatusRedisPersisterActor will send back a reply to its StatusRedisSyncActor parent containing the topic and informing it of this action. 4. If the StatusRedisSyncActor receives a notification from its StatusRedisPersisterActor that a new entry was added to the StatusDB then it will send off this topic to ConverterActor which will convert the "topic" into what we call a "request". 5. Afterwards the ConverterActor will send this newly converted request off to the RequestRedisSyncActor. This RequestRedisSyncActor will then send the request to its RequestRedisPersisterActor child so that it can be persisted into the RequestDB. 6. The RequestRedisSyncActor also has a RequestRedisListenerActor which listens for changes that occur in the RequestDB. In this case, it will pick up the fact that a new request was added to the RequestDB by the RequestRedisPersisterActor in step 5 and it will send if off to other parts of the service for further processing. As you can see there is quite a lot going on so we want to be sure we're on the right track. A question that we had is: Are we creating too many Redis-related actors, and is there a more generic way to organize the Redis persisting and listening functionality for the 3 databases? Initially we expect the system to have somewhat of a light load, with very few changes a second in the TopicDB, but this could change as the system evolves. Luis -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
