Ниже выкладываю часть ТЗ. 

ya.mihailovich(sob)gmail.com 

Модуль динамического сбора информации 

Задачи 
• Первичная инициализация данных (разовое наполнение БД) 
• Периодическое обновление (месяц, квартал) 
• Ежедневное обновление 
• Расчет статистических данных на основе полученной статистики (ежедневно) 
• Веб-интерфейс позволяющий производить мониторинг системы и ее администрирование 

Бизнес слой 
Три блока данных, которые необходимо обрабатывать. Компании и их продукты. 
1. Банки и банковские вклады 
2. Управляющие компании и ПИФы 
3. Форекс брокеры и ПАММ-счета 

Эти три типа компаний и их продукты независимы друг от друга, имеют разный набор параметров, статистики, источники и периодичность сбора информации. 
Обработку этих трех блоков нужно сделать в разных независимых модулях (отдельно запускаемых, сбой в одном модуле не влияет на работу в другом). 
Общий фреймворк для трех модулей допустим и приветствуется. 

Прокси 
Через веб-интерфейс задаются параметры прокси-сервера. Вся работа идет через него. 

Ресурсы 
Так как будут запускаться 1000 задач в день, нужно иметь в виду вопрос памяти. Чисть ее постоянно. 

Язык 
Не PHP.  Не Microsoft family. Что-то многопоточное, умеющее долго работать без перезагрузки, не течь по памяти, хорошо умеющее парсить. 

Замечание об удалении данных 
Никогда не удаляем данные из БД. Вместо удаления – помечаем как 'архивный'. 

Требования для парсеров 

Каждый парсер должен вести свой журнал: 
1. Активен ли он в данный момент 
2. Какой элемент обрабатывает сейчас 
3. Когда был запущен последний раз 
4. За сколько обработал последний элемент  
5. Сколько неудачных запусков 
6. Среднее время обработки одного элемента 
7. Среднее время работы всего цикла 

Управление парсером 
1. Запустить любой парсер вручную в любой момент 
2. Остановить его работу в середине выполнения 
3. Поставить его на паузу (не будет запущен по расписанию) 
4. Добавить новый поток (если данный парсер не однопоточный по бизнес логике – парсесер небольшого файла однопоточный, парсер 900 графиков – многопочный) 
5. Уменьшить ко-во активных потоков 
6. Для задач по расписанию иметь возможность указать с каким количеством потоков стартовать 
7. У компаний и продуктов должен быть флаг – активен это элемент для парсинга или нет. (Т.е. помечаем некий банк как 'не обновлять данные' и при следующем проходе парсер не будет рассчитывать статистику для него, или для УК не будут обновляться графики для ее ПИФов или для конкретного ПИФа). 

Добавление/удаление/редактирование парсеров 
У каждого парсера есть урл с которым он работает. Он должен быть виден в админ панели. 
Некоторые парсеры уникальны и индивидуальны (парсинг файла с ПИФами). 
Один диспетчер обновления графиков ПИФов (900) и 900 парсеров. Этот список должен быть доступен в админ панеле. Там мы имеем возможность редактировать/удалять эти парсеры.  
Так 900 парсеров будут очень сходы между собой, то хочется иметь возможность добавлять новые без участия программиста, просто через интерфейс (как пример: указать урл данных, формат csv/json/etc, дать название). 

Пересчет/устранение ошибок 
Если парсер пропустил несколько запусков, он должен получить все данные, которые пропустил. 
Мониторинг изменения данных 
Если парсер обнаружил новый банк, новую УК, новый ПИФ или исчезновение таковых, то они должны быть в статусе «ожидает проверки». До подтверждения оператором этот элемент не участвует ни в каких операциях. 

Интерфейс администратора 
По специальному УРЛ (логину и паролю) должна показываться страница управления мониторинга пасерами. Три независимых страницы управления (три типа продуктов) плюс общие настройки. Тут должно быть доступ все, что было описано выше.  
Дополнительно: 
• Простой просмотр всех данных из БД (без супер дизайна, но достаточно юзабильно), т.е. все, что парсеры собрали, должно быть доступно здесь. 
• Возможность редактирования и удаления каждого данного 
• Добавлениередактирование  пользователей 
Типы доступов: 
• Полный 
• Только чтение 
• Изменение (без удаления)