Qwiery was not build with scalability and tight security in mind. It was build for simplicity and ease of use. If you wish to go hyperbolic then the following notes will be helpful.
File based. The way QTL and other data is stored in flat JSON files is obviously not ideal. Take MongoDB, DocumentDB, CouchDB or any NoSQL instead. Use Redis for caching.
GraphDB. The flat JSON structure used to store the semantic network is fun to use to see and alter things but it won’t work well with million of entities. Use Neo4J, ArrangoDB and look into RDF technology. On the NodeJS platform you can look into LevelGraph and LevelDB. Proof of concepts (read: Qwiery variations) have been developed with key-value stores and high-tech backends, the flat JSON files were retained for the sake of simplicity and ease of deployment. We wanted to keep the threshold as low as possible.
Parsing. The way the oracle service is parsing input is based on regular expressions and this also does not scale well. The enterprise version of Qwiery is based on SQL and NoSQL which deal with parsing much more efficiently. The main issue with the currently implementation is the lack of hierarchy and clustered index. Either you can find these mechanisms are part of the storage or you need to look for specific services. If you wish to replace the text-based input with natural language then the problem shifts towards NLP solutions and parsing is solved. One can in principle hook up Qwiery to e.g. Microsoft’s cognitive services or alike and still keep a fair level of intelligence within Qwiery. For example, you can only use the speech recognition API but deal with the answer yourself.
Service delegation. Take weather related info. Qwiery allows both a push and pull scenario. The easiest way to unload server processing would be to send to the client an instruction to request the data from a service (Yahoo weather, say). The ReactJS framework is useful in this context because it wraps the calling and the rendering in one component. Well, you can use Kendo UI, AngularJS or anything as well. The point here is that you can process response as little or a much as you like. This is in fact true for the side-processing as well: you can remember as much as you need about the user. If topics and emotions are irrelevant to your domain of interest then there is no need to keep those services.