Иван Шумов

Поставить перед своим api GraphQL и агрегировать все на лету

Если для программирования стало мало и хочется 4к то кто-то пишет очень и очень плохой код. Раз много открытых процессов то проще ещё пару мониторов поставить - квадратом. Один большой монитор хорошо только на маках - когда у тебя отлично с множеством виртуальных десктопов

Select t.*, Count(t.id) z from (select ..... Union select ....) As t Group by t.id having z = 2

- Тюнить конфиг кролика
- Тюнить конфиг сервера
- Мониторить логи
- мониторить параметры сервера (диск, проц, память, одновременное число сообщений)
Перестать пользоваться принципом fire and forget и контролировать в скрипте факт успешной доставки сообщения в очередь с exponential retry

Можно не мучиться и использовать готовые решения - называется Identity Server. Можно поставить самому: Keycloak, например. Или попробовать SaaS: Auth0. Я назвал только самых ярких представителей.

Если же хочется сделать самому то надо организовать маппинг токенов из соцсетей и пользователей в своей системе, а так же делать не мало так элементов управления всей этой махиной

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

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

Только если делать редирект. Можно, конечно, выеживаться, но оно того не стоит

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

С фрилансерами одного канала связи не будет никогда - не путайте с аутсорсерами. И ваш таск-мннеджер им тоже не сдался

В зависимости от того какой процесс в компании там может быть что угодно: от трелло до редмайна и джиры

Выделяем отдельный Identity Server, который следит за пользователями. Читаем про всякие oidc, OAuth2 и тому подобное. Каждое приложение это отдельный сервис, который ничего не знает про другой. Если пользователь гость то его отправляют поговорить с IS, залогиниться и прийти обратно с токеном (все это под капотом с редиректами или через Ajax)

Прифит. База пользователей одна, приложений сколько угодно

Проблем у вас несколько. Первая с latency, вторая с source of truth.
Первая решается через CDN и репликацией инстансов с логикой. Гарантированно придёте к очередям и асинхронной обработке данных с событийной консистентностью.

По базам - либо полностью менять логику приложения и коммуникации, либо использовать распределенные базы, такие как AWS Aurora и AWS DynamoDB. Сами по себе они региональные, но есть интересные фичи, позволяющие выводить на весь мир.

Сразу скажу - коллизии будут в любом случаем

Изменение структуры данных называется миграция и это абсолютно нормальный процесс, его не надо бояться. Чем проще меняется структура данных тем сложнее вам написать качественную логику приложения. Формат JSON или нет вообще не должен интересовать по тому что в логике это объекты и все постоянно трансформируется.

Вопрос версионирования лежит в другой плоскости и не зависит от базы данных.

Не стоит думать про преждевременную оптимизацию. Ws это не про то чтобы было меньше запросов и логику приложения куда сложнее продумывать чтобы было прямо хорошо

Идти в IAM и генерировать пользователям креды для cli. И разрешать им, соответственно, этот вид доступа.

Очереди ваше все. Redis, RabbitMQ и другие) а там только воркеров добавляй сколько надо

Перестать ломать голову и начать настраивать роутинг вебсервера, а не переносить проблему в код

Нет, не нужно. Совсем