d'Ivan

Excelsior JET некогда решал данную задачу.

Возможные причины:
1. Хостинг видео медленно отдает файлы.
2. Неустойчивая мобильная связь или недостаточная ширина канала.
3. Плохая аппаратная поддержка кодека видео.
4. Излишне загруженный JS скриптами сайт.

ClickHouse (CH) вроде бы хорош для таких целей.

Я бы установил какой-нибудь gem APM типа New Relic / Scout - любой, который умеет вести мониторинг Sidekiq.

https://buildingvts.com/monitor-and-debug-bottlene...

https://dotnet.microsoft.com/apps/aspnet/hosting
MySQL SaaS:
https://www.jawsdb.com/
https://www.cleardb.com/#pricing
и пр.

Использовать (durable) очереди сообщений или буферизованный канал (указав длину канала), способный вместить достаточное количество сообщений (например, 100) Но если программа получит сигнал прерывания, то они будут утеряны. Поэтому 1-й вариант надежнее.

а reader считывал только свежие данные.

Если в сообщении отправлять атрибут времени отправки, то получатель может отбросить сообщение, если оно стало неактуально.

Попробуй Game Extractor

безопасно хранить ключ

Можно хранить в хранить в Hashicorp Vault, доступ по API.

https://devcenter.heroku.com/articles/error-codes#...

Бот должен прослушиваться на порту, указанному в файле Procfile в качестве сервиса web, который команда heroku ps должна показывать при выводе.
Документация.

sorter := func(i, j int) bool {
		return arr[i] < arr[j]
	}
	sort.Slice(arr, sorter)

UPDATE (SET a = 'foo' where field и LIKE '%pattern%')

Нужно было перед командой добавить "EXPLAIN ANALYSE ", тогда можно было узнать план запроса, не выполняя его.

3. Почему UPDATE не связанный с этим полем так тормозит?

См. выше.

Особенно когда

Есть таблица на 100 млн записей.

Кроме того, что за индекс был добавлен на поле, по которому выполняется LIKE? Если B-tree, Hash, то это имеет нулевую ценность для ускорения запроса. По этому полю возможно нужен GIN индекс (pg_trgm). Или даже необходимо перепроектировать таблицы, вынеся это поле, разбив на множество записей и связью N:M. Мы не знаем что за данные в том поле.

Для экспериментов лучше создавать ограниченный набор данных, приближенный к продакшн и тестировать на нем, вместо на 100М записей.

Есть 3 endpoint во flask, которая возвращает json. Есть 4-й endpoint, который асинхронно обращается к 3-м выше и собирает итоговый json.

Зачем? Используй очередь сообщений и отдельный процесс для сбора данных с fetch_url. Клиент не должен ждать пока данные будут получены. Вместо этого для получения результатов можно использовать запросы short polling к серверу или сервер будет сам уведомлять через SSE.

Можно установить тонкий клиент, например, Thinstation

Для индексации файлов можно взять Solr, работающий на том же движке.

Для Heroku есть решение