A little Parse trivia a gathered from talking to (very capable) Parse engineers that now work at FB:
- Still the world's largest MongoDB user
- Had 1M apps, largest one with 40M users
- Server was Rails at first (24 threads max. concurrency), later rewritten in Go
- >40 MongoDB Replica Sets with 3 nodes each. Storage Engine: RockDB (MongoRocks). No sharding (DB-to-replica-set-mapping). Only instance storage SSDs, no EBS.
- Write Concern 1 (!) - some people complained about lost data and stale reads (slave reads were allowed for performance reasons)
- Partial updates were problematic as small updates to large docs get "write amplification" when being written to oplog
- Experienced frequent (daily) master reelections on AWS EC2. Rollback files were discarded -> data loss
- Special flashback tool that recorded workloads that could be rerun for load and functional testing
- JS ran in forked V8 engine to enforce 15s execution limit
- No sharding automation: manual, error-prone process for largest customers
- Indexing not exposed: automatic rule-based generation from slow query logs. Did not work well for larger apps.
- Slow queries killed by cron job that polled Mongos currentOp and maintained a limit per API-key + query combination
- It was planned to migrate Parse to FB's infrastructure but the project was abandoned
- Clash of clans used Parse for push notifications and made up roughly half of all pushes
I find this extremely interesting, as we are building a BaaS, too, but have a very different approach (Baqend). Coming from a database background, our idea is that developers should know about details such as schemas and indexes (the Parse engineers strongly agreed in hindsight). Also we think that BaaS is not limited to mobile but very useful for the web.
Also I think that providers should be open about their infrastructure and trade-offs, which Parse only was after it had already failed.