deepblack

GPS, сеть, батарея, пуш - как минимум, акселерометр, камера и микрофон - желательно).

Фукнционал простой

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

хотя бы на уровне "70% общей кодовой базы

от таких решений постепенно отказываются, в реальном мире это оказывается слишком дорого

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

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

1. Можете начать с реализации отправки запросов и получения результатов, но результаты запросов просто игнорируйте без всяких преобразований. Сравните Go и Node между собой и с лимитом в 3 секунды. Если вышли за 3 секунды, думайте, как получать результаты быстрее или поднимайте лимит.
2. Если вам нужна скорость, то нужно ли вам полноценное преобразование тело-запроса -> json -> объект -> БД? Можете ли вы обойтись более короткой цепочкой, например тело-запроса -> нужные поля -> БД?
3. Для Go можете попробовать https://github.com/mailru/easyjson или аналоги, если структура объектов известна заранее. В этом случае преобразование json -> объект должно быть быстрее, чем со стандартной библиотекой.
4. Для Go эта задача вполне в его нише - реализация должна быть простой. В общем случае что-то типа N горутин на выполнение запросов, M горутин для конвертации результатов, K горутин для записи в БД. Обычно K=1 и в этой горутине можно писать записи в БД пачками (batches), что быстрее, чем по одной записи.

Весь день голову ломаю.

За день уже могли бы реализовать на том, что знаете (nodejs) и если не устроит по результатам, попробовать Go.

Достаточно просто подумать "Чем я пользовался на этой неделе?", выбрать одно из существующих приложений и попытаться его повторить.

Очевидно обработку делать в фоне, используем очереди (queue), можно в том же redis.
Дальше простая математика, например:
Если одна задача из очереди обрабатывается в среднем за 0.5 секунд то вам понадобится минимум 222 обработчика очереди чтобы успевать обрабатывать 445 задач в секунду
Каждый обработчик требует ресурсы сервера (CPU, RAM) и исходя из этого уже можно обозначить требования к машине где это будет крутиться
Желательно БД сервер и redis сервер запускать на отдельных машинах чтобы нагрузка от них не мешала работе приложения.

Надо понимать что высокие зп это это либо зажравшиеся компании типо финтеха когда у них денег жопой жуй и они выдают за на рынок 500к в месяц
Если брать фриланс это обычно эффективность, то есть приложение за 1000 баксов где обычные программы делают 100 часов вы делаете за 2 дня то есть за 60 баксов в час

То есть если я плачу человеку 100 баксов то это либо очень маржинальный а проект либо человек сам по себе эффективен и работает в разы лучше среднего программиста на рынке

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

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

Поднимаешь VPS с вордпресом заграницей. Вопрос решен
Либо ставишь vpn клиент в СИСТЕМУ и заворачиваешь нужный трафик внутрь впн.

Вордпресс это сайт. Как он должен блин к впн подключаться?

PXE загрузка сервера
https://habr.com/ru/articles/136921/
например тут почитайте

По сути три больших направления с кучей мелких ответвлений
1. хранить текстовый лог в отдельном файле/сервисе/логохранилище
2. хранить лог действий юзеров в отдельной таблице (встречал один проект, где лог действий был в десятки раз больше, чем сами данные, ага).
3. хранить в той-же таблице предыдущие записи. То есть при редактировании INSERT, а не UPDATE, при этом автоматически проставляется время и автор, а при выборке просто берете последнюю по времени версию.

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

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

С учетом "использоваться будет, я надеюсь редко" я бы остановился на текстовом логе. Отдельный лог на каждую запись, можно архивировать старые, можно logrotate натравить.

В документации есть гайд для новичков. Там все описано.