Иван Шумов

Как уже сказал BasiC2k - модульность проекта спасение в данном случае. Вообще, я большой сторонник предварительного проектирования контрактов. Это совершенно не типичный подход к разработке что сегодня, что 20 лет назад, но при заминке на старте позволяет безболезненно масштабировать команду на дистанции. В этом плане очень хорошо ложится на микросервисную архитектуру и при правильной архитектуре позволяет раздать в разработку разные части системы нескольким командам, которые даже не до конца знают что вы там строите.

Один нюанс - нужен сильный архитектор из вашего домена)

Ну, проблема в концептуальном не понимании что такое аналитика и Warehouse или Data Lake.
Во-первых давайте определимся чем аналитика отличается от метрик, агрегатов и отчетов.

• Аналитику делают люди, не регулярно, скорость для них не важна
  
• Отчеты происходят автоматически на регулярной основе. Для них важна периодичность
  
• Метрики нужны чтобы что-то измерять во временном ряду
  
• Агрегаты - сбор данных из разных источников вне зависимости от остальных факторов
  

Если мы все еще говорим про аналитику то она не должна обращаться к живым данным вообще. Ее складывают в отдельный Warehouse или Data Lake и анализируют по необходимости. Основными инструментами являются Power BI, Tableau или даже пресловутый Excel.

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

Если мы говорим про метрики то для них отдельный сервис строится, из которого получают дашборды, API и все в таком духе

Единорогов не существует. В принципе даже если взять 2 пункта из 4, любые - таких брокеров гарантированно быть не может. Как минимум по тому что 0 и 1 - несовместимые с жизнью требования, а 4 не является вообще зоной ответственности очереди. Ну и в догонку - пункт 2 где-то может и есть, но есть миллион причин так не делать

Подключите Яндекс Метрику и научитесь ей пользоваться. Делов-то

Итак, для начала DigitalOcean - НЕ ОБЛАКО. Это просто набор связанных сервисов. Зайти в DigitalOcean очень просто, выйти тоже, все понятно и прозрачно но там даже горизонтального масштабирования нет. Это слегка прокачанные те же VPS-ки.

Теперь по всему остальному. Есть золотая троица AWS/Azure/GCP, но тут начинают играть другие правила.

1. Стоит обратить внимание на то что им действительно надо учиться и это занимает время. Чтобы сделать решение, а не поделку и не влететь на деньги месяца не хватит ибо там очень много всего.
   
2. Я могу сказать что переезд из одного облака в другой возможен при двух условиях: вы пользуетесь только базовыми сервисам (вроде виртуалок, БД, S3) и у вас есть 2 архитектора с сильным пониманием этих облаков
   
3. Два архитектора по тому что я не знаю ни одного такого человека кто потратил достаточно сил и вник сразу в несколько облаков достаточно глубоко. Я был там везде и в результате все-равно остановился на AWS, хотя Azure и GCP имеют свои преимущества
   
4. Про сервисы - ехать в облако и не пользоваться особыми сервисами и фичами этого облака - дорого и глупо
   
5. А самое интересное что сделать и мигрировать проект проще чем обучить людей и изменить подходы к прайсингу
   
6. Миграция в облако и из облака - не делается по щелчку пальцев, особенно если есть много данных
   

По AWS могу поделиться гайдами как туда ехать, да и у них Cloud Migration очень понятный раздел с документацией. Если сравнивать эти облака то:

• AWS - serverless, cutting-edge solutions, прозрачная инфраструктура
  
• Azure - экосистема от MS, прекрасный CosmosDB (но это скорее про цены)
  
• GCP - глобальные ресурсы, BigData
  

При этом большинство этих фич в том или ином виде есть в других облаках.

И маленькая ремарочка по k8s. Если вы едете не в GCP то он вам не нужен. AWS и Azure сделали так что вы можете его туда удобно загнать, но это будет дороже. Тот же AWS ECS + Fargate куда удобнее и я не знаю тех System Engeneer что по собственному желанию пересаживались с этого на k8s

Готовиться к собеседованиям вне зависимости от его типа - бесполезно. В данном случае в равной степени с вами как могут просто поговорить по душам так и прогнать по жести ещё раз. Играть в угадайку бесполезно

Да, это нормально. Но можно и разделять. Благо прокси, трансформирующие rest в soap и обратно уже существуют

Хост это виртуальное пространство. Никто напрямую с машиной игрока кроме серверов игры не взаимодействует

Как уже писали - Node.js для бэка. Очень активно сегодня используется, например, в Serverless разработке, скилах для ассистентов, чатботах и много где еще

Пересылать ссылками, как есть. Любой клиент сможет загрузить изображение и его отрендерить. Фигней страдать не стоит

Да и да. Но все в любом случае упирается в бюджет