Иван Шумов

Делайте уникальный ключ вида UUID, например, а все параметры храните на сервере. Так можно будет ещё контролировать одноразовость операций

Стоит задуматься скорее о том как будет использоваться API. Вот представьте - чтобы получить коммент надо знать id пользователя и поста. Нужна ли системе данная сложность? Мне кажется нет.

В REST в принципе делают связанные сущности таким образом только когда они не существуют . как . глобальный список (например у пользователя есть статус и его надо менять отдельно GET users/:id/status, PUT users/:id/status)

А правильного варианта нет, есть подходящий

У данного региона для s3 два эндпоинта. Это Легаси и у них это отдельно указано в документации. Фиксить не собираются

Задумались на счёт Ansible - отлично. Его собраться это Chef, Puppet, Salt

То о чем вы говорите является несколькими различными задачами. Доступ пользователей и роли это базовый принцип RBAC. Если несколько систем или она распределённая то стоит задуматься про Identity Server.

Логирование это отдельный срез и это делается как сбор access logs с вебсервера. Потом это можно положить в базу и анализировать, например, с помощью ELK стека.

Если надо ещё объединять по пользователям то вперёд и с песнями реализовывать свою систему по тому как access log вам надо анализировать по заголовкам и записывать в базу ручками. Тут готовых решений нет, вернее есть, стоят денег и вряд ли изменяются под чьи-то требования.

Данные по доступа к ресурсам можно снимать с proxy или балансировщика как вариант

Во-первых проблема у вас не в нагрузке,мама том что у вас архитектура не предполагает масштабирование при такой посещаемости. Shame of you

Все данные по одному запросу звучит дико - данные должны отдаваться в минимальном объеме для функционирования того или иного модуля и только по запросу.

GraphQL придуман как лекарство от тонны REST ресурсов и микросервисности