Правильная архитектура сканнера арбитражных ситуаций?

Приветствую всех участников сообщества! Хочу воплотить в реальность свое давнее желание: написать свой собственный сканнер коэффициентов букмекерских контор. Задача не из простых. Краткое пояснение для тех кто не знает что это. Сканнер букмекерских контор (он же «вилочный сканнер») — это парсер который ежесекундно парсит коэффициенты сотен событий на десятках букмекерских контор. Далее он «склеивает» все события и ищет между ними т.н. «арбитражные ситуации». Думаю — в целом задача понятна. И важный нюанс: речь идет о т.н. live-событиях. Т.е. события, которые идут прямо сейчас.

Думаю над правильной архитектурой такого сервиса. Какие пока мысли:

1. Изначально отказаться от стандартных СУБД (like MySQL), ибо в базу ежесекундно (а то и чащще!) нужно скидывать текущие значения коэффициентов с тысяч событий. (К примеру — в субботний вечер в час пик на разных конторах транслируется 200 событий на разные виды спорта. Нужно например парсить 30 контор. 200*30 = 6 000 трансляций. А контор, необходимых для сканирования — гораздо больше 20). Конечно же коэффициенты обновляются не каждую секунду. Но на динамичных видах спорта — очень часто. И нужно рассчитывать на то что в такую базу будет прилетать 6000 запросов обновления в секунду.
2. Продолжение п.1: вместо стандартной БД использовать «In memory DB», т.е. что то, что висит в оперативке и обновляет данные максимально быстро. Сохранность данных здесь вообще не важна, ибо через 3 секунды актуальность данных уже пропадает.
3. С одной стороны в эту базу будут писать данные парсеры, с другой стороны ежесекундно к этой базе ежесекундно будет обращаться функция построения итоговой таблицы тех самых арбитражных ситуаций. И уже к этой итоговой таблице будет обращаться вебсервер и по выбранным фильтрам пользователя будет показывать ему таблицу интересующих его вилок/валуев (тех самых арбитражных ситуаций). Кстати — у пользователя будет открыта страница, которая будет рефрешиться тоже раз в секунду. А учитывая что пользователей может быть тысяча — то и таких запросов тоже будет прилетать 1 000 в секунду.
4. Что касается самого парсинга. Раньше каждую контору парсили по своему: какая то контора обновляла данные через сокеты, какие то — обычными http-запросами. И все существующие подобные сканеры посылали свои запросы через сокеты, или формировали свои http запросы. Но сегодня это все уже работает плохо, ибо конторы защищаются от парсинга разными методами. И самый простой и самый универсальный способ парсить данные — это парсинг браузером. Т.е. вы просто открываете в браузере страницу события и парсите ее. Но конечно же — за такую универсальность придется заплатить ресурсами. Каждая такая страница будет занимать мегабайты в оперативке. Предположим одна страница в среднем занимае 20 МБ оперативки. Тогда предполагаемые 6 000 открытых страниц займут 6 000 * 20 МБ = 120 000 МБ = 120 ГБ оперативки. Конечно, это нужно делать на нескольких серверах.

Какие проблемы я вижу в данной архитектуре:

Насколько я понимаю — если использовать In Memory DB, то и весь процесс парсинга должен происходить в этой же оперативке. И сам вебсервер должен быть на этом сервере. И это конечно же мягко говоря — неудобно) С другой стороны — если процесс парсинга выносить на другие сервера — то как доставлять данные в оперативку, где концентрируются все данные. Это ведь все таки не MySQL. И если под вебсервер выделять отдельный физический сервер — то как он будет получать доступ к InMemory DB, которая крутится в оперативке другого сервера? Вобщем — InMemory DB генерирует как ряд преимуществ, так и ряд проблем)

Прошу у сообщества умных размышлений, советов и критики ))