[DivineTraube]

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.

[greenleafjacob]

Even with higher levels of "consistency" Mongo is still unsafe [1].

[1]: https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

[DivineTraube]

That is definitely true for some of the older versions of Mongo. Still, a quorum write concern will yield far fewer consistency violations. An interesting trade-off to take: losing a little data is better than losing a little latency.

[hota_mazi]

> which Parse only was after it had already failed

You just listed some pretty impressive metrics, Parse was acquired for $85M and yet, you still think that Parse failed?

I'm curious what you would call a success.

[nodamage]

A product that is acquired and subsequently shut down because the acquirer has no interest in it is indeed a failed product as far as I'm concerned, even if said acquisition was a financial success for the investors and employees.

[hota_mazi]

It was acquired because it was successful.

The failure is 100% on Facebook's side. They could have decided to keep the business up, they decided no to.

Thankfully, Google is doubling down on a similar business, so we have alternatives.

[DivineTraube]

Of course, it's a little unfair to declare it failed. The exit definitely was impressive. However, the product still died. It's hard to tell without the real business metrics whether this was due to lack of sustainable revenue and growth or just missing alignment with FB's overall strategy.

From a standpoint of traction it was no failure. A lot of developers liked it for a good reason. However, the pricing model and the lack of performance guarantees lead Parse to being used for prototype stuff in the free-tier mainly. I think, if they had a little more trust in the capabilities of developers to know what they are doing, the service might still be alive.