I’m curious about the tech stack behind Pandorabots and how it scales and handles the number of bots it hosts.

I once had a bot hosting site for RiveScript bots; it was a simple single-web-server Perl web app, and I went with a RunABot-style approach where a bot could choose a “base brain” to use (with options being Alice or Eliza). If the bot didn’t have its own trigger to match a user’s message, it would fall through to the base brain to get a response.

None of the RiveScript implementations are very good at handling a brain the size of Alice (~90K AIML patterns, which can be consolidated into slightly less RiveScript triggers). Most of them take numerous seconds to load the replies from disk, and a couple seconds to fetch a reply. If a single server was running multiple instances of an Alice-RiveScript bot, the CPU load would be real.

So, I programmed a daemon that would load Alice and listen on a TCP port. The web app front-end would connect and get a reply when it needed to fall through to the Alice base brain. This way the Alice brain only needed to be loaded one time and was kept active on the system to be able to give a response at any time. Also, my web app had limits on the number of triggers a user’s bot could have, so that users couldn’t just upload their own copy of Alice.

Because RiveScript is generally “fast enough” on reasonable sized brains, the general workflow of getting a reply for a user was along these lines:

[ol][li]1. User requests the web app API to get a reply[/li]
[li]2. The web app loads the RiveScript brain from scratch (loadDirectory(), etc.)[/li]
[li]3. If no reply is found, it tries to connect to the TCP port for the Alice bot and get a reply and disconnect.[/li]
[li]4. If the Alice bot TCP port isn’t available, fall back to Eliza (a second instance of RiveScript loaded on-demand from disk).[/li][/ol]

What is the high level architecture behind Pandorabots? How can it handle so many different bots?