1. Общая суть проекта
Мы делаем вебсервис. В данном обсуждении мы абстрагируем от конкретной потребности клиента, которую он удовлетворяет. В целом, пользователь может в рамках вебсервиса настроить выполнение сервисом на регулярной основе нужных пользователю задач. Например, пользователь может настроить задачу, который должна запускаться вебсервисом каждый день с понедельника по пятницу с 7:00 до 21:00 каждые 2 часа.

2. Архитектура системы. Вижу примерно следующую архитектуру, позволяющую реализовать вышеописанную систему.

Вкратце опишу. Клиент (Customer) авторизуется в User Panel. Там он создает и настраивает задачу. Эта информация попадает в Customer task config database. Тут же в настройках задачи задается расписание запуска. Эта информация попадает в Task Schedule Database. Controller Server выступает чем то вроде планировщика Windows + системой очереди (вроде MSMQ). В соответствии с настройками запуска в Task Schedule Database, Controller Server периодически добавляем задачи в очередь (вроде MSMQ). Каждый отдельный экземпляр Worker регулярно проверяет очередь на появление задач и при появлении задачи забирает ее из очереди и начинает выполнять. Результаты выполнения задачи отправляются в Processing result database, откуда их может просмотреть покупатель в виде отчета в своей UserPanel.

3. Требования к системе. Самое главное требование к системе - возможность в будущем в рамках данной архитектуры и финансовых вложений в аппаратные ресурсы сделать ее отказоустойчивой. В нарисованной мною модели мне неясно как сделать отказоустойчивым Controller Server (то есть как его можно клонировать на несколько разных машин). Все остальные участники системы - с ними проще: сайт можно разместить на облаке; Worker машин несколько, если одна в какой то момент выпадет - ничего страшного. Все используемые базы можно разместить на кластерах.

4. Тезисы и вопросы. Заметим, мы не уверены, что все тезисы важны, но все же их перечислим.
a. Возможность прогнозирования нагрузки. Поскольку пользовательские задачи поставлены на расписание, у нас есть возможность прогнозировать с большой долей достоверности нагрузку на систему обработчиков в определенный промежуток времени с точностью около получаса.
b. Мы понимаем, что в мире множество вебсервисов и скорее всего существует большое количество готовых решений подобных задач. Предпочтение отдаем именно готовым. Изобретать велосипед не хотим. Если вы знаете готовые фреймворки или технологии для подобной реализации, будет просто отлично.
c. Облака или не облака? С учетом возможности прогнозирования нагрузки задумывались об использовании облачных решений вроде Azure для расположения на них обработчиков. Чтобы это работало примерно по такому принципу. При этом сравнив с тем же хецнером понимаем, что по ресурсам дешевле взять несколько хецнеров (необлачных), чем аналогичный по мощности тариф Azure с возможностью масштабирования мощности в зависимости от количества текущих задач. С другой стороны, возможно на больших объемах задач Azure будет выгоднее. Опять же, здесь нам нужно мнение эксперта.
d. Может связка Task Schedule database + MSMQ вообще не нужна? Возможно, есть более правильные решения реализуемой задачи? Тем более, с учетом того, что хотелось бы, чтобы Controller Server в будущем можно было тоже сделать отказоустойчивым. В контексте этого мне неясно как будут синхронизироваться обработка таблицы расписания и очереди, если Controller Server будет работать на нескольких компьютерах одновременно.

Перевести б табличку