a) Depends if you run with replication and how you've configured your writeconcern (w and j values). https://docs.mongodb.com/manual/reference/write-concern/#ack...

This is giving you the choice where in the CAP triangle you want to be.

As you can see the default of w:1 and j:null when run in non replicated mode does not write journal to disk before ack. If you want better guarantees read some best-practice articles, most of them recommend w: majority, especially when run in replication.

c) no issue

d) $lookup works fine and is as old as 3.2, but as with any join, if you try to combine 2 tables with millions of rows each, performance will be bad. That said it's not as good as RDBMS here. No foreign keys or voodoo under the hood optimizations for example. Mongodb sales people will always say that you should model your data differently, without really giving good examples of such. But really - even if multi document queries exist, you should not continue modeling data as BCNF and think of mongo as a drop in replacement for RDBS, the domain should be suited for denormalized documents to begin with.

If you mean fetching/updating foreign-key-related documents by "multi documents queries", I wouldn't do it in RDBMS too. There's no special magic inside RDBMS made those queries much better than fetching related docs manually, but there are always some dark corner cases which will bring your database to full stop in most unfortunate times.

Why do you think some simple joins would risk to "bring your database"? It is code which is used all the time by tons of applications and not "some dark corner cases".

Try to figure out how it will work if both tables are sharded between partitions and some junior engineer will implement `LIMIT x SKIP y` REST pattern on that `SELECT FROM a INNER JOIN b` request with non-primary index sorting, for example.