There may be a misunderstanding here about sharding vs replication. Having the same data distributed across a few data centers for data locality is done using replication. Sharding means that data is partitioned horizontally to achieve higher throughput, or other goals. See here for a good discussion: https://stackoverflow.com/questions/11571273/in-mongo-what-i...
MongoDB's multi-document transactions work with replication today, and will work with sharding in 4.2.
To answer one of the questions in the post: I do believe that MongoDB's transactions will only be used in some applications, and only in few but critical places within those applications. That is because with a document database, data that belongs together will often already be together in the same document, rather than distributed over multiple tables as with a traditional database. And if it's together in the same document, you can already modify that atomically in MongoDB without multi-document transactions. (Disclosure: I work for MongoDB.)
And I would still claim that this is easier in MongoDB because several versions of the phone number field(s) can happily coexist in the same collection. Those variants are usually trivial to understand for someone who even just looks at the data, and the application can be written to either accept the different formats, or adjust the format on the fly when it encounters a document that still uses an old schema. Or you could indeed write a batch job that bumps all your phone numbers to a new format, and you could put a JSON schema constraint on your collection that enforces the new schema for every future document. All those possibilities exist, and I truly see that as a big advantage.
The short answer is: just do it. You can add any field to any document at any time. That's the beauty of JSON documents without schema constraints. Then of course you need to let your application understand that. But it turns out it's almost trivial to make an application display a phone number field if it finds one, and not display a phone number if there isn't one in the document.
I am one of the team of MongoDB engineers working with Epic on this issue, and I can assure you that the situation is under control and we have everything in place to scale this application to much higher numbers. However, we're not publishing details about our support cases, especially while they are in progress. That is something for Epic to decide, and I do assume they will eventually say in public just how well MongoDB is, in fact, performing for them.
I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now available. There is no speed impact on cases when you don't use them. And most of the time, you shouldn't use them, otherwise you wouldn't be capitalizing on the advantages of JSON. I think that's a game changer, but then again: I do work for MongoDB.
WiredTiger shows a lot of potential, but it would be irresponsible to make such a radically different engine the default for everyone, even for new databases, without giving it some time to mature.
Six minutes sounds about right to me, if the food is not complex. Try using a stopwatch next time you're in a restaurant. The service industry is pulling some pretty amazing stuff, all the time.
MongoDB's multi-document transactions work with replication today, and will work with sharding in 4.2.