Иван Шумов

Самый простой способ это short polling - опрашиваем регулярно APIs на предмет новых данных.
Чуть посложнее - Long polling - это тоже самое, но тайм-аут дольше (обычно порядка 20с, золотой стандарт)
Еще усложняем - websocket
Еще более интересно - push notifications

Со стороны сервера в любом случае надо генерировать какие-то события или уведомления и хранить для каждого пользователя чтобы клиент мог их получать. Тут подойдет как таблица так и очереди (message broker)

При смене стека все-равно будет просадка. Из моей практики это 1 позиция - мидл падает до джуна, сениор до мидла или даже ниже. Если навыки и теоретическая база на высоком уровне то вернетесь на нужный уровень достаточно быстро, если нет - мои соболезнования.

Надо понимать что категории выдают людям за то насколько глубоко они знают технологию с которой работают и насколько эффективно выполняют задачи. Сохранение категории я видел всего несколько раз - у ряда джунов, которые не определились в стеке и у пары довольно упорных сеньоров, но это были реально золотые ребята.

По гарантиям вам никто не скажет - мы не знаем что будет завтра и насколько вы готовы к изучению новых языков. Можем с тем же успехом подбросить монетку или погадать

Правы все, но при этом никто не может ничего сказать у вас по делу. Могу посоветовать начать хотябы с функциональной декомпозиции что ли, написания user stories. После этого сможете выделить из них то что касается MVP, что является зависимостями, приоритизировать и эстимировать отдельно, а где-то запрашивать исследование

Это только первая часть архива. Нужно получить остальные)

AWS S3 сам по себе не достаточен. Стоило его обернуть в AWS Cloudfront. Вообще ваша проблема не в скорости чтения, а в скорости доставки контента до пользователя. Еще стоит посмотреть не стриминговые решения

Ну, для начала подключаться из интернета к RDS вообще плохая идея, не надо так.
По делу:

RDS:
- проверить Publicly Accessible yes
- проверить RDS security group порт 3306 на 0.0.0.0/0 (а лучше ваш IP)

По сети:
- проверить Route Table на предмет того что трафик из Internet Gateway идет в Subnet где запущен RDS

Мммм, какой классный холивар, давайте я вставлю свои 5 копеек. Сначала прелюдия:
Redis:
это кэш с парой-тройкой фич. Не предназначен для хранения и поиска данных как класс

Elasticsearch, Sphinx:
Два принципиально разных поисковых движка. Хорошо делают свою работу, но не предназначены для хранения данных, только для хранения поисковых индексов.

1. Хранение данных каталога с быстрым доступом

Поскольку ни одна их указанных систем не является базой данных стоит задуматься о другом виде баз данных. В зависимости от того что выберете то и масштабировать придется по-разному

2. Поиске по информации, в особенности русскими названиями-запросами

Это умеет сегодня любой поисковый движок

3. Простота в использовании: синтаксис запросов, документация

Документация есть у всех адекватных поисковых машин, синтаксис везде достаточно простой

4. Наименьшая нагрузка на "железо"

А вот тут начинаем смеяться. Если мы говорим о поиске то первое правило - все выделенные ресурсы что вы выделите будут съедены. Даже если у вас 100 товаров по 2кб. Память будет съедена первой, потом получит свою порцию и процессор

5. Отказоустойчивость

Это не про поиск, а про архитектуру, сеть, сервера, и все в таком духе. Если что то горизонтальное масштабирование поисковых машин это боль - все хорошо пока не сломалось и там очень часто кластер не восстановись

6. Безопасность

Опять не про поисковые машины. Есть 3 части: encryption in transit (ssl), encryption at rest (AES), auth (зависит от движка). В принципе все и так поддерживают сегодня

7. Масштабирование

И снова не про поиск, а про архитектуру. Вертикально масштабировать проще всего в облаках и дорого, горизонтально масштабировать - больно