Архитектура приложений типа datanyze.com?

Насчет нужности такой информации можно глянуть хотябы пример кейса из статьи на хабре habrahabr.ru/company/cloverr/blog/217117 (Компания KISSmetrics, и у них главный конкурент – компания Mixpanel. Ребята из KISSmetrics каждый день отслеживали, кто начинал использовать Mixpanel и просто звонил всем тем и предлогали рассмотреть их продукт.) Это всего лишь один из кейсов на самом деле их гораздо больше. Но не об этом речь.

Конечно можно написать простенький код обхода миллиона сайтов, к примеру, в 200-350 потоков и сохранять все в бд изпользуюя пул. Но, как мне кажется, подобные стартапы явно разрабатывают не так. Да и одной таблицей там тоже не обойтись. Ведь приложение должно проектироваться с расчетом на изменение требований: что если сайтов станет не миллион а 100 миллионов, признаков для фингерпринта более 10,000 и т.д. Под аварийным завершением я подразумевал скорее проблемы на аппаратном уровне (сбой сети, и т.п.). Потоковая модель так же со временем может упереться в ограничения железа, поэтому возможно нужно смотреть в сторону iocp для widows или epoll для *nix систем, но тогда между парсером и базой должна, я думаю, появиться прослойкак в виде очереди. Так как с таким потоком дисковая подсистема может не справится. DNS резолвинг тоже может стать одной из проблем при работе с огромным кол-вом доменов. Ну, и т.д. и т.п.

Хотелось услышать именно об этих тонкостях.

Twindo: мысль понял, выходит это фактически услуга "поиска заинтерисованных клиентов". Все вышеперечисленное универсально я думаю решить нельзя, но на уровне проектирования решается легко.
Для легкой масштабируемости нужно отделить массив сайтов от массива результатов, далее пишется процедура, которая "резервирует" часть массива для отработки и передает их одному из серверов кластера, отдельный сервер отрабатывает свою "порцию данных" и складывает в отдельный массив, сервер результатов собирает данные с массивов и концентрирует у себя. В целом получается комплекс из N серверов обработки, и 2 или более серверов хранения, либо кластеров SQL. Все этапы отработки независимы между собой и практически не вызывают конфликта доступа. Реализуется легко например на платформе Azure, масштабирование получается "из коробки".