Существенным ограничением node.js является то что движок JavaScript в любой момент времени может выполнять ровно один скрипт или часть скрипта, если в скрипте используются функции обратного вызова или промисы.

Если на сервере доступно несколько ядер то можно запустить кластер node.js. Проще всего это сделать при помощи PM2 см. pm2.keymetrics.io/docs/usage/cluster-mode При этом практически не придется делать изменения в приложении. За одним исключением. Нельзя использовать глобальное состояние (например значение переменных которые определены на уровне модуля, подписку на сообщения и т.п.) т.к. это состояние будет у каждого экземпляра свое. При необходимости для синхронизации глобального состояния дополнительно приходится использовать как правило redis-сервер.

Статья на которую Вы ссылаетесь содержит две распрстианенные ошибки в использовании JWT.
1. JWT используется для того чтобы не нужно было ходить в базу данных за данными пользователеля. Данные пользователя хранятся в JWT. Это немного увеличивает нагрузку на сеть, но сразу снижает в два раза количество запросов в базу данных. А это критично для нагруженных сервисов. Кроме того позволяет вынести авторизацию в отдельный миуросервис.
2. Вы наверное спросите а как же быть, если данные изменятся. Для этого сокращают время действия токена до минимального значения. Чтобы не проходить повторно процедуру авторизации, для возобновления действия этого токена выдается долгосрочный токен, предъявив котрый можно обновить краткосрочный токен и тем самым получить обновленные данные.

Возникает вопрос а что делать если пользователь был забанен или как в вашем случае разлогинился. Или просто его критически важные данные поменялись. Для этого организуют реестр аннулирования токенов, в котором записи хранятся на время действия токена. Такой реестр будет иметь сравнительно небольшой размер так как время хранения краткосрочных токенов невысоко. Его лучше организовать на быстрой базе данных key/value.

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

Другой способ хранить в таблице и в токене идентификаторы открытых сессий и при обновлении токена проверять не закрыл ли сессию пользователь. Такой способ позволяет в частности организовать логин только с одного устройства когда новый логин закрывает все другие сессии. И реализовать принудительный разлогин клиентов с одного устройства или из админки.

Про разлогине нужно еще иметь в виду что он всегда будет немного сбойной операцией. Так как во время разлогина может отсутствовать интернет и вызов api закончится со сбоем.