Иван Шумов

Ну, для начала подключаться из интернета к 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. Масштабирование

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

Даже если сейчас вы будете звездой за безумное число денег то границы закрыты на ближайшее время. После открытия границ будет полно уволенных IT специалистов на внутреннем рынке и страх компаний перед миграцией сотрудников, поэтому советую спокойно дорасти до senior в одной специалистом чтобы рассчитывать хоть на что-то.

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

Итак, куча всего смешана, давайте разбираться. У нас имеется:
- X различных сервисов с различными интерфейсами
- отсутствие транзакционности
- отсутствие гарантии доступности сервисов
- необходимость это все контролировать

Как в реальности это решается:
- Saga Pattern - отличная вещь, появилась именно как микросервисная транзакционность
- нам потребуется оркестрация. Я не очень в курсе что сейчас по on-prem решениям но из моего мира есть AWS StepFunctions. Ищем аналоги для своего энва
- если нет готовых решений то придется строить свою событийную архитектуру на очередях с брокерами и медиаторами
- для проблемы не доступности сервисов придется использовать exponential backoff или exponential retry. Опять, же, в моем мире это решает AWS SNS.

Вообще, во времена до облаков я такое делал на RabbitMQ и смекалке, но с любыми такими системами встает проблема валидация контрактов, так что только вам решать на какую часть переносить сложность.

usort в помощь

Менял в сервисе когда сдох магнитный накопитель (за год работы всего). iMac был 2012 года, комплектация на 1Tb (с новым iMac Pro такой проблемы не наблюдается). Проблема - вертикальное расположение диска. Заменить лично я бы не рисковал - там экран приклеен и надо очень аккуратно снимать с феном и на специальный клей это сажать. Делают, благо, довольно быстро, но надо понимать что могут понадобиться еще салазки.

Официальную документацию

Во-первых есть запросы, а во-вторых есть разные виды кэширования: Read-Through, Write-Through и другие. У всех есть свои минусы и недостатки. Кроме того под капотом в таких системах чаще всего внутри все работает на очередях или стриминге

До определенного момента не играет роли. В данном случае причинами делать несколько лямбд может быть:
- увеличение безопасности (разные права у каждой лямбды)
- увеличение перформанса (разные подключаемые модули и разные настройки, включая память)
- разная логика
- поддержка разных версий
- разделенное логирование

В принципе, все)