Сразу же сообщу, что в данной публикации не сравниваются Fullstate и Stateless парадигмы построения серверов. Также отсутствует какая-либо агитация в пользу Fullstate. Мы исходим из ситуации, в которой мы приняли решение, что для конкретного проекта сервер ASP.NET должен между запросами не только хранить какие-то статические данные, но и возможно выполнять какую-то полезную работу.
При этом мы, разумеется, хотим использовать всю мощь DI-контейнера .NET!

Иногда хочется автоматически создавать текстовые файлы, подставляя в шаблоны значения каких-то полей. Например, это могут быть исходники классов-хелперов на основе какого-то интерфейса, какие-то отчеты в XML, которые хотя и можно сгенерировать полностью программно, но на практике это может быть достаточно трудный для сопровождения код. Наверное, те, кто сталкивался с такой потребностью, смогут дополнить этот список. Приведу для примера задачу с хелперами.

Можно считать это продолжением публикации Кастомный JsonConverter: уменьшаем связность и экономим ресурсы. Там при рассмотрении списков верхнего уровня упор был сделан на десериализацию из JSON. Но чтобы что-то десериализовать, нужно сначала это сериализовать. Посмотрим, чем нам может помочь возможность сериализации IAsyncEnumerable<T> объекта.

Рассматриваем некоторые возможности, которые нам предоставляет кастомный JsonConverter.

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

Так что предположим, что запрос на полноценные сессии всё же имеется. И эти сессии надо как-то утилизировать после окончания их срока жизни. Навскидку можно предложить следующие решения.

Запуск параллельной задачи при очередном запросе с клиента.

Запуск специального потока.

Использование таймера.

Всё же осмелюсь предложить ещё одну идею.

Обновление: благодарю @Politura - комментарий о MemoryCache оказался очень полезным! Проверил и решил так и сделать.

Одно из двух, — прошелестел он, — или пациент жив, или он умер. Если он жив — он останется жив или он не останется жив. Если он мёртв — его можно оживить или нельзя оживить.

А.Н. Толстой. "Золотой ключик, или Приключения Буратино"

Пользователю лень фильтровать запрашиваемые данные, а их бывает довольно много. Заставлять пользователя что-то фильтровать - негуманно и попахивает произволом. В таком случае пользователь сидит грустит, ругает разработчиков, давит на техподдержку. Если сделать "в лоб", сервер по запросу клиента будет собирать для отправки коллекцию объектов, загружая их из базы или ещё как-то. Потом всю эту махину он пошлёт в ответном HTTP-пакете, предварительно серилизовав в JSON, там это всё будет в один присест десериализовано в клиентские объекты, которые, наконец-то предстанут пред взором потерявшего надежду пользователя.