nekkie

Вы раскрыли слишком мало информации о себе, чтобы дать дельный совет (который, как верно заметили, еще и никто не знает).

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

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

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

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

ИП на упрощенке
или самозанятый

но все это скользко, конечно

Придется платить 30%

Сильно ли вы проиграете от обёртки данных в пару лишних килобайт? Это легко вычислить: 2 кб * 1e4 = 20 мб. Для игрового сервера это очень мало.
А зачем это делать? Вы не умеете работать с tcp? Вы не знаете как поддерживать соединение на tcp? Вы делаете браузерную игру, обёрнутую в мобильное приложение?

Это называется long polling . Можно погуглить особенности решения по этому термину.

Вот случилось у меня 1000 CCU - будет ошибкой такое решение? 10000?

Глобально или на физический сервак? Это ж разные вещи. Как я понимаю, всё-таки в расчёте на физический сервак. Но и сервак-серваку рознь, как и само CCU беp "профиля нагрузки" мало что говорит.

В целом, ответы на такие вопросы проще получать экспериментальным путём (собрать простой прототип и натравить на него ботов).

приходят запросы, сервер на них не отвечает сразу, как только все запросы пришли и логика отработала - на запросы отправляется ответ.

Для прототипа и 1000 CCU точно хватит, если ходы не частые. Например, я по такому принципу сделал дебажный матчмейкер.

Если бы не было мультиплеера (когда пользователь просто ждёт что-то), то покатило бы и для прода.

В случае мультиплеера (когда пользователи ждут друг друга), не вижу преимуществ перед поддержкой обычного соединения, кроме сэкономленого времени на разработку MVP. Минусами же станус костыли для поддержки соедиенения и определения дисконектов. Для случая низкуоровневой работы с tcp есть куча мануалов и "стандартных" решений. В случае работы на уровне не ниже http могут возникнуть непредвиденные проблемы из-за промежуточного софта и самого протокола.

Кроме того, при простейшей реализации long polling одно из соединений будет забито на обработку одной команды и послать другое будет нельзя. А значит потребуется делать отдельные http запросы на каждую дополнительную команду. Теоретически можно загнаться и сделать передачу нескольких команд через такое соединение, но это уже ничем не будет отличаться от собственного протокола через tcp (кроме дополнительных тормозов и костылей).

С другой стороны, ничто не мешает делать два запроса: один на отправку команды, другой (периодический) для получения результата. В запросе на отправку команды можно предусмотреть небольшую задержку, на случай если ход будет произведён почти сразу после получения команды.

Резюме:

- если есть экспертиза и время: делать нормальную коммуникацию через tcp
- если экспертиза не очень и сроки не горят, то делать нормальную коммуникацию через http с двумя командами (отправить изменения, получить текущее состояние)
- если нужно ещё вчера, то long polling подойдёт.