Hi,



We are evaluating Kinvey for a mobile application. We do have a few open questions that seem to be unaddressed by the publicly available documentation:



* How does the Kinvey backend actually work? Specifically: Do we as customer share a multi-tenant MongoDB deployment with other customers? Is the Node.Js server for the business process-level isolated from other tenants? Who are both partitioned and replicated? These points are important to us, as we have a background distributed systems and databases and would not trust a system with unknown internals.

* What is your approach to scalability? It seems like you do not expose sharding rules nor indexes? That seems vastly undercomplex for any serious data-intensive application.

* What is your appraoch to availability? Specifically: with which write concerns are updates propagated to MongoDB - to be consistent or to be available?

* What is your approach to concurrency control? We could not find conditional updates, version-based OCC nor transactions. How would one implement even such as simple thing as a counter without running into race conditions? Through business logic? This would then imply that the business logic tier is not scalable/replicated over more than one machine.



Thanks for your help!

Hi Franz,

Firstly I apologize for the delay on this, these are great questions and they've prompted us asking our engineering team to draft up something that goes over the specifics in more detail; that process is just taking a bit of time.

In the publicly available freemium kinvey.com, the environment is shared. Our application level code is responsible for ensuring multi-tenancy boundaries. At the high end of pricing options you could get your own environment (in a separate VPC including dedicated hardware), which is still hosts multiple apps, but is single-tenant with respect to an organization. To learn more about that you can talk to sales.



Approach to indexing is addressed here - https://support.kinvey.com/discussion/200476047/How-to-create-indexes-on-collections-for-faster-queries. We want to take care of scaling for you, and to be the ones that worry about shards, indexes, or load balancers.



Our service is not a general-purpose database and we do not expose a complete set of APIs that a bare MySQL or a MongoDB offers. A good way to get an understanding of what is a good fit for our platform is to look at our case studies. If your use case isn’t similar, feel free to contact sales.