basrach

Квантировать. Также как и делает операционная система с процессами. Процессов много, а центральный процессор один. ОС просто даёт маленький интервал времени каждому процессу, все выполняются по очереди и все счастливы.
Самый простой способ - разбить весь массив на пачки по 100 (10, 1000), между обработкой пачки делать тупо Thread.Sleep(300 или меньше), давая тем самым обработать запросы серверу. Параметры подобрать экспериментально.

Я не проверял, но должно быть как-то так:

var transactionList =
		from transaction in _context.Transactions
		from destinationUser in _context.Users
		from destinationUserWallet in destinationUser.Wallets where destinationUserWallet.Id == transaction.DestinationWalletId
		from sourceUser in _context.Users
		from sourceUserWallet in sourceUser.Wallets where sourceUserWallet.Id == transaction.SourceWalletId		
		where destinationUser.Id == User || sourceUser.Id == User
		select new 
		{ 
			sourceUserName = sourceUser.Name, 
			destinationUserName	= destinationUser.Name, 
			transaction
		};

.RegisterType().As().PropertiesAutowired()

Этим самым вы сказали, что хотите чтобы Autofac, при создании экземпляра класса Lol произвел инъекцию во всего его (объекта Lol) публичные свойства. Чтобы работал ваш пример, нужно сделать тоже самое но для типа UniversityController.
А вообще лучше не использовать инъекцию через свойства. Никогда.

Классика. А ля "диагноз по фото 16x16px".
Ошибка в методе RP.WebUI.Arm1Search.SetDataSet(DataSet ds) +16 инструкций от начала метода. Написано же.

Несмотря на то что сами куки присутствуют, у них есть срок действия. Обратите внимание на него, возможно он слишком короткий.

Уживутся. Подводных камней нет, кроме того что сами можете временами путаться что у вас через EF, а что через Nhibernate.

По сути вам просто нужно взять и настроить готовое решение для SSO. Посмотрите, например, на IdentityServer, его относительно просто установить и настроить. В вашем случае нужно будет просто добавить нужный middleware в pipeline asp.net core.

Вахтершу.
А так, да. Identity де факто стандарт.

Пунктуация и стилистика бросается в глаза, вы можете аргументировать типа "не на писателя устраиваюсь же", но встречают по одежке, знаете ли...
По коду.
Вот вы говорите DDD, а похоже на Transaction Script. Поскольку в классе FeedLoader в каждом не-query методе происходит сохранение изменений, т.е. нет понятия бизнес транзакции. В данном случае это не особо нужно, но раз уж вы про DDD заикались... Также богатой изолированной модели не видно. Возможно в данном случае опять же эту богатую модель неоткуда взять, потому как предметная область тривиальная. Но тогда выходит, что вы выбрали неправильный способ решения задачи. В модуле Core у вас какие-то классы, очевидно для сериализации, непонятно что они делают в Core. Да и вообще, если бы увидел код без описания, мне бы никогда даже не закралась мысль, что его создавали по DDD.
API не REST, хотя в требованиях было про REST.
Нет конфигурирования кэша, что, где и насколько кэшировать. При этом само кэширование реализовано в BusinessLayer, что странно, поскольку кэш, как и, например, DataAccess, это чисто инфраструктурные вещи.
Логирование только в API и только ошибок.
В тестах нет моков. И похоже что тестирование только интеграционное, т.е. без базы данных не получится протестировать ничего.
Пустой catch в ApiTester. Да, это не основная кодовая база, но когда не работает и при этом не сообщает почему не работает, всегда бесит, даже если это тесты.
Итоговая оценка зависит от ваших ожиданий и ожиданий ревьюверов. Если вы junior, и на эту же то позицию претендовали, то вполне неплохо. Если senior, то зависит от уровня ревьюверов/проекта/компании и т.д.

Посмотрите на сигнатуру второго вызова AddScoped. В Visual Studio это можно сделать наведя указатель на метод.
Она будет такой: AddScoped>(x => ... Т.е. в контейнере регистрируется не Some, а Task. И это нормально, асинхронный метод всегда возвращает Task. Чтобы зарегистрировать Some, нужно чтобы лямбда внутри AddScoped была синхронная, этого можно достичь написав либо ...GetSomeAsync().Result, либо еще как-то получить результат, и непосредственно его уже возвратить.

Вам нужны два разных контекста. Контексты, это те классы, которые наследуются от DbContext, и абстрагируют доступ к БД. Один для одной базы, другой для второй базы. Соответственно и конфигов у вас будет по числу баз данных, т.е. тоже два.

вы упустили слово await перед context.SaveChangesAsync();

1. Найти файл настроек IIS: %WINDIR%\System32\inetsrv\config\applicationHost.config
2. В этом файле найти секцию applicationPools, найти там нужный appPool, добавить/заменить атрибуты на autoStart="true" startMode="AlwaysRunning", должно быть типа такого:

<applicationPools>
  <add name="DefaultAppPool" autoStart="true" startMode="AlwaysRunning" managedRuntimeVersion="v4.0">

3. Найти секцию sites, в ней нужный site, а там нужный application и добавить туда в тег application два атрибута: serviceAutoStartEnabled="true" serviceAutoStartProvider="ApplicationPreload"

<sites>
    <site name="Default Web Site" id="1" serverAutoStart="true">
        <application path="/" serviceAutoStartEnabled="true" serviceAutoStartProvider="ApplicationPreload"

4. Ниже, прямо после секции sites или перед закрытием тега system.applicationHost добавьте:

<serviceAutoStartProviders>
    <add name="ApplicationPreload" type="MyNamespace.ApplicationPreload, MyAssembly" />
</serviceAutoStartProviders>

Обратите внимание! Значение name должно совпадать с значением serviceAutoStartProvider.
Значением type должно быть полное имя класса-загрузчика (неймспейс, сборка), который будет запускать quartz при старте сайта.
5. Реализовать собственно класс-загрузчик:

public class ApplicationPreload : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        // Qurtz.Net.Start() // или как там хз
    }
}

При этом надо помнить, что пул может быть всё равно "прибит" IIS-ом, например, если исчерпан лимит по памяти. Необработанное исключение в вашем коде может его также остановить. Но после остановки он должен сразу же запускаться. Т.е. нельзя надеяться что некий код будет работать 24/7. Он будет прерываться, но сразу же запускаться.

Также, лучше код запуска qurtz-а (тот что в методе Preload(string[])) повторить в методе Application_Start в Global.asax для надежности.

Можно.

Контексты не знают друг о друге ничего, и нет никакой разницы, создаете вы два экземпляра одного класса контекста, или два экземпляра разных классов контекстов. Каждый экземпляр полностью изолирован и функционирует так, будто он один на свете. Т.е. в него можно пихать любые таблицы/сущности и мапинги лишь бы они были корректны с точки зрения схемы бд.
Единственный минус возможно заключается в том, что какие-то маппингы придется дублировать в двух местах. Таким образом возможно могут быть нарушены принципы вроде DRY и еще какие-нибудь. Но, как предложили выше, наследование закрывает этот вопрос.
В любом случае окончательно решение нужно принимать с учетом всех особенностей вашей архитектуры.