Иван Шумов

Разве не логичнее сразу, из первого приложения добавлять сообщение в rabbitmq

Да, это логично. Но сохранение в БД я бы также оставил по простой причине - консистентность. А то на больших объемах кролик может терять данные + иногда есть необходимость повторной обработки (CQRS/Event Sourcing)

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

Как я вижу архитектуру :
1) Amazon api gateway получает запрос с вебхука телеги.
2) Перекидывает его в amazon Lambda
3) Та делает минимальное логирование/метрики и прокидывает дальше в очередь Amazon SQS
4) Дальше очередь разбирается n бекендами (для начала той же Lambda), если это "быстрый" овтет - отвечает юзеру в телегу, если "сложный" - кладёт в SQS и уже это сообщение подбирается другим специальным отдельным EC2 инстансом.
бд : Amazon DynamoDB для удешевления и скорости.

Да, абсолютно нормальней подход

В случае перерасхода средств пути для удешевления :
Пункты 1 и 2 перекидываются на EC2 или инстанс digital ocean'а,

Или AWS ECS + Fargate с scale to 0. В нагрузку получим бонусом работу с контейнерами. И еще придется же все-равно делать троттлинг по скорости отправки. Сколько там сегодня - все те же 30 сообщений в секунду?

1) Имею небольшой опыт работы с prometheus и grafana, хотелось бы и тут их использовать. Подскажите как нынче проще всего интегрировать их? Им нужна своя бд? Проще ли и дешевле ли будет это всё хостить на DO или же сносно будет и на AWS?

дорого, долго настраивать и почти бесполезно в AWS

Что можно использовать для сбора логов сегодня из разряда дёшево и сердито?

В идеологии AWS - ничего кроме CloudWatch. Вне AWS используйте что знаете - все-равно самостоятельно разворачивать.

TS есть и на бэк, разумеется в виде трансформации в JS (Node.js это просто рантайм в котором запускается js). Если хочется прямо каноничной разработки - Java only. Можно PHP со строгой типизацией, можно Go, но я его не оценил.

Что до функционального программирования то сегодня оно есть в одном виде по-сути и это serverless (FaaS) и там Nodejs заходит более чем полностью

Да. Ну, кроме call-back

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

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

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

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

"Смешались в кучу кони, люди". Попытка описать систему вообще со всех сторон пользы не принесет, да и не возможно это в целом сделать понятно и наглядно. Стоит начать хотяб с use-case диаграммы чтобы понять какие есть actors, а оттуда уже можно будет сделать компонентную диаграмму и пойти дальше. Условия клепать это не про проектирование, а если все что я перечислил является сложным для вас то возьмите просто mindmap