Technical requirements

This is a list of requirements for the platform and database, as I think of them:

• Reasonable price: I need to be able to get up and running for no more than a few hundred dollars a month, and scaling needs to be no worse than linear in cost.

• Wildcard domains: we want the hosting provider to host *.querki.net, and route all traffic within that into the servers. The subdomains are semantic, and will be handled by the code. We could make use of something like Apache to map those subdomains to paths, but the important path is that the hosting provider can cope with receiving arbitrary requests without requiring a CNAME record for each subdomain.

• Semi-persistent nodes: our architecture demands that a given node is typically up for at least a fair while. Doesn't have to be months at a time, but it is unacceptable to bounce servers every hour.

• Good communication architecture between nodes: the Querki architecture assumes a farm of relatively homogeneous nodes, which are communicating frequently. A user may be attached to node A, which needs to efficiently communicate with a Space instantiated in node B.

• Fast database loads: we don't actually care much about write speed for the DB, since that will typically be done in the background. But load throughput needs to be fast, since we are loading a lot of objects at once.

• Capable of heterogeneous documents: note that, for the moment, we don't much care about being able to index into those documents; they could potentially be blobs. But they are blobs of highly variable size (from a few bytes to tens of K each), and that must be handled well. Ideally, the DB would be capable of introspection on the key-value pairs of the documents, but that is not yet a requirement.