Рассмотрим масштабируемый высоконагруженный сервер, работающий со множеством клиентов. Пул потоков, потоки обрабатывают юзерские запросы, код абсолютно stateless, все данные юзера хранятся в расшаренной РБД. Профит такой модели — во-первых, надежность: падение отдельного потока не приводит к потере данных, интерфейс РБД предполагает транзакционность. Во-вторых — "гербалайф с таймшером": в каждый момент времени только один из N юзеров парит сервер запросом, а значит утилизация мощности происходит в N раз эффективнее, чем при индивидуальной работе. Разумеется, запросы на ресурсоемкую обработку данных нежелательны, т.к. один такой запрос может сожрать все ресурсы сервера, а желательно, наоборот, кеширование, индексирование и прочие вещи, которые позволят отстреливаться от клиента как можно быстрее. Это была трепетную лань.

Теперь рассмотрим коня, то есть классическое десктопное приложение, например, декомпрессор типа WinRAR'а. Все в памяти, если используются классы — в них полно член-данных, юзер работает с интерфейсом непрерывно, а уж если "делает запрос", то отжирает кучу ресурсов в ходе процесса. Профит такой модели — ну, надо ведь и такие "жоркие" задачи где-то решать, это раз. Два — программировать state-классы привычнее для многих. Три — это еще и сравнительно эффективно, т.к. при явном "фокусе" некоторого процесса есть все шансы, что его виртуальная память маппится на оперативную.

Вопрос, который меня интересует — есть ли какие-то наработки по конвергенции этих двух моделей? Статьи, библиотеки, проекты и так далее. Допустим, есть ультратонкие клиенты, которым надо обрабатывать документы. А они их даже у себя хранить не хотят. Писать алгоритм обработки на T-SQL в таких случаях не вдохновляет, а часто вообще есть код приложения для толстых клиентов, который хотелось бы развивать синхронно. Как люди выкручиваются?

P.S. Кассандрствую: лет через 10 этот вопрос приобретет острейшую актуальность.