Любым способом запустить в отдельном потоке/процессе

но там просто дурацкий внешний апи, нужно сравнивать достаточно вложенные структуры и на это уходит норм CPU времени

Может можно оптимизировать

надо через профайлер прогнать тогда чтобы понять где жрет больше всего ресурсов)

Если это итерации, можно разбить на итерации и запускать в тасках, конечно, но не уверен, что это лучшее решение)

Можно сложные цпу операции запускать в отдельном приложении, которое будет из очереди забирать задачи, потом его горизонтально масштабировать

Это для совсем тяжёлых

bull/rabbitmq можно взять для доставки задач

+++, у меня не такие масштабы

Это да, но просто такая схема хорошо масштабируется достаточно

Т.к. redis и rabbitmq можно запускать в кластере тоже

Ты не ограничен тогда ресурсами одного сервера

Не всё нужно масштабировать

Но для простых юзкейсов воркер-треды норм вполне считаю, но я не интересовался их бенчмарками

Работа с другим потоком не медленнее, чем тоже самое через промежуточную среду

Да, но там как бы тоже есть такой момент, что память тяжело шарить между воркер-тредами

Задам еще по другому вопрос: у меня с внешнего апи приходят вебхуки когда изменилась сущность на другом сервисе, я это ложу в очередь (сейчас это bull), и потом делаю запрос на этот апи чтобы получить сущность, провести некоторые сравенения/вычисления у себя с БД, и если надо, обновить запись в моей базе. Таких хуков приходит до 500 в минуту, и когда столько приходит, ЦП на все 100% начинает юзаться и другие запросы на простые выборки с бд по моему апи уже начинают тупить, я правильно понял что нужно вынести вот это вычисление в отдельный воркер / и оптимизировать его?

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

Да, просто надо учитывать, что тут появляются все проблемы тредов

считайте эти сущности многоуровевнеыми документами с массивами