Как правильно организовать архитектуру веб-сервера?
Ох. Ну давайте подряд. Начнем с конца :-p
3) Мгновенного поиска не бывает. Так что нужно сразу понимать необходимой быстродействие. Кому то и 1500ms "мгновенно", а кто то хочет за 10ms данные получить.
 Критические вопросы:
- какой объем данных в базе всего
- какое количество поисков случается в секунду
- насколько поисковые запросы избирательны (ответ на поисковый запрос это единицы записей или десятки тысяч)
- насколько консистентна и релевантна должна быть поисковая выдача с учетом постоянных апдейтов.
- сколько есть денег на сервера ;-)
Если данных мало (< 1gb плюс минус) я бы не парился и записал это все в обычный mysql навешав на него 100500 индексов. Дальше нужно померять производительность на запись-чтение, если все устраивает - на этом и остановиться.
Если данных больше и хочется освоить что то новое - я бы посмотрел в сторону Elastic Search.
Ребята из 2gis как раз пару лет назад его внедряли https://habrahabr.ru/company/2gis/blog/213765/ документации по нему море. Из минусов - выдача всегда будет отставать от горячих данных.
Если нужен поиск по горячим данным и при этом быстродействие mysql не устраивает - у меня нет хорошего ответа :) Можно какую нибудь кассандру посмотреть, можно свой велосипед напилить, но тут советовать лично мне - сложно.
2) Нода, питон, руби, пхп - дело вкуса абсолютно. Основная нагрузка (если речь не идет про велосипеды) будет все равно на БД идти. А велосипеды лучше на C++ писать такие.
1) По Вашему посту у меня больше вопросов чем ответов если честно. Что за json, откуда они берутся, как будут разрешаться конфликты если новые json приходят быстрее чем обрабатываются старые, итд.
В целом это более тривиальный вопрос чем задача быстрого поиска.
Если известно конечное число характеристик - делать одну таблицу, в идеале - поля должны быть уже известны. Тогда проще работать с индексами и не нужно подключать связи таблиц. Это серьезно ускорит работу бд.
1. Структура будет зависеть от среды, нода джанго или пых - все они будут по разному подходить к задаче в силу ограничений/преимуществ среды. По пыху - взять ченть полуготовое, например ларавел, хотя из задачи торчат уши хайлоада, тут в идеале нужно писать свой шустрый велосипед. Но мвц - без сомнений. По остальным - не в курсе что сейчас модно.
2. Нода и джанга - не сервера, а фреймворки. 
3. Я бы смотрел на мускуль. При правильной настройке скорость работы современных рбд практически идентична, а информации по настройке/работе с мускулом просто через край. Комюнити широкое и достаточно отзывчивое, спецов на рынке есть. Если нужно надежно/быстро/поддерживаемо то в экзотику типа мемористораж баз я бы не кидался. Результат мгновенно - это только у пургена, любая программная компонента имеет задержку, на поиск, индексацию, внутреннюю передачу данных, структурирование и прочую накладную фигню.
PS: кто такая логинация???