Network or database connection problems are rare but will happen. They should be anticipated and prepared for when they interact with data integrity guarantees, which are one of the most important parts of making a piece of software enterprise ready. In this case, they're most likely to crop up in one of the worse places for them to crop up: if the LRS is receiving multiple large batches of statements at once. I know no Mongo insert is atomic across multiple documents, but it'd be worth at least batching them into a single insert call to reduce error possibilities (plus you'll find that a single insert call is much, much faster when receiving large batches due to reduced network roundtrips).

If you wanted to create a truly enterprise ready LRS, I'd recommend writing 'unactivated' Statements initially (in a bulk insert), then using a search-based update to target exactly that set of statements, which you then activate. (Easiest way: make your 'inactive' attribute contain a UUID that's unique for the insert set, so the search is trivial; update is just removing the attribute or setting it to false). Again, since the updates aren't atomic across a document set, you can't guarantee hitting them all, but both a cleanup operation is possible, and you can atomically store the list of Statements that need to be made active (then remove it once its succeeded) and periodically check for remaining activations. Since single Statement requests are most common but can be done in a single atomic call, you can special case those to insert already activated, so the average overhead is basically zero.