Architecture patterns for collective intelligence engines

Architecture patterns for collective intelligence engines

With the advent of web based technologies and the associated increase in user base that comes with it, organizations that truly have a desire to learn more about how to satisfy their customers use data analysis and intelligence learning engines. Great examples are of course web services like amazon.com.

Collective intelligence - An architectural guide for scalability and efficiency

A good basic intelligence engine would consist of synchronous and asynchronous services. These services can be web based and/or have an offline set up.

Synchronous services service need to be fast because clients are waiting on the results of its processing.
In order to ensure proper scaling and high performance, synchronous services should be stateless i.e. the service instance should not keep track of any information during its round trips between the client and the intelligence engine. All the data needed for such services to successfully perform their tasks can be saved in a persistant data store or in a cache.
If there are multiple instances of such services running together, they should be behind a well configured load balancer.

Asynchronous services are typically in the back ground. Examples of this kind of service include the kind of data collecting web service which I created for an intelligence engine which recommended TV shows, movies, books, images, music and other media [the recommendation list was then delivered to either the users cell phone, a personalized web portal or a personal inbox on the users TV].

The asynchronous service that I created was stateless. It would accept the data that was passed onto it and go on to complete its intelligence task. As soon as it was done, another load of new data would then be handed to it, from a queuing system, and it would continue to chug along to do what it was supposed to do. Asynchronous services can be used for tasks which are longer and take more computation. Things like predicting user preferences, indexing existing data bases, calculating item ranks etc for individual users are examples of computational activities where asynchronous services could be used with greatest benefits.

The diagram attached shows a glimpse of the entire architectural layout. The request generated could come for a variety of media types e.g. video, music, blogs etc. The synchronous interfaces will directly contact the pre computed data sources to retrieve lists of potential ‘you might like these’ items. Such items are populated in the precomputed data cloud by the data crunching that is being handled by asynchronous services. A real time event, in our case the request, will carry new information on what is being asked for and will initiate the process of updating or creating new recommendations.

Creating or updating recommendations in real time

If the architecture shown here is implemented as an event driven SOA, it will allow real time update or creation of new recommendation items for the user. As soon as a new request is sent to the server, it will pass it onto the intelligence engines in the back ground. The next time the user interacts with the system, he should be able to see updated pre computed data for himself.

An example would be of amazon.com. As soon as a user engages in an event like searching for a book, a message is sent to the intelligence engine. The engine will then perform the relevent actions and the next time the user goes back to amazon.com, he will see that his recommendation list is different from the last time he logged in.
Similarly, if a user identifies a recommended item as being one he does not like, the intelligence engine is notified of the event. The recommended items list is re computed and presented again to the user. See attached screen shot from amazon’s recommendation list for a user :

Amazon Example

About the Author