Если частичное наличие или отсутствие данных в разных коллекциях может сломать бизнес-логику, то реализовывают двухфазовый комит (
https://docs.mongodb.com/manual/tutorial/perform-t... ), либо выбирают транзакционную БД. Однако часто такой проблемы нет, и предварительно созданные документы в отдельных коллекциях не оказывают влияния на бизнес-логику, пока ссылки на них не попадут в некий "главный документ" (например, пока вновь созданный заказчик не попадёт в заказ, который и нужно создавать после всех "подчинённых" документов в качестве факта обработки запроса пользователя). Лучше не "довыполнять" запросы после падения сервера, а наоборот игнорировать "повисшие" записи. И можно завести некий garbage collector, подчищающий мусор без нужных связей (однократно запускаемый при запуске БД, или только при запуске после аварийного останова). Не стоит планировать отказ БД как основной сценарий обработки запросов, иначе отвлечётесь от задачи интернет-доставки к задаче построения подземного бункера с серверами.