Василий Банников

Что должен возвращать mysite.com/redirect пользователю?

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

Если не упарываться в NoSQL, то можно классическим реляционным подходом - EAV-паттерн применить.
Если постгрес, то можно его в документ-ориентированную базу превратить, благодаря jsonb полям.

Я бы ввёл две таблицы:
1. "Описание услуги" - с перечислением всех полей, которые должны быть указаны в заявке. (чтобы можно было сформировать форму)
2. "Заявка" - там все специфичные поля записываются в jsonb-колонку.

GraphQL позволит гибко настраивать payload для внешних API

Мне кажется, что в этом случае GraphQL не очень подходит, так как у контрагентов может быть свой интерфейс взаимодействия => всё равно в коде нужно будет реализовать коннектор для каждого.

Тут напрашивается Redis.
1. Ничего страшного не произойдёт, если разок при вводе капчи пользователя попросят ввести её ещё раз, если на стороне твоего Бэка что-то потеряется.

2. Если ты создаёшь большой сервис с кучей клиентов, то ты можешь захотеть горизонтально масштабироваться - тогда твой сервис должен быть stateless, а по тому никакого состояния в памяти у отдельного экземпляра быть не должно.

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

1. Зачем вообще нужны усложнения, почему в рамках ваших сервисов не использовать rest api (обычный голый http с json-ами)?
2. grpc vs rabbitmq - это больше вопрос про синхронное vs асинхронное взаимодействие.
В зависимости от конкретного случая может быть лучше одно, а может быть лучше другое.
Как правило при использовании api gateway имеет место синхронное взаимодействие, тк ожидается, что сервер ответит на http-запрос в течение пары секунд (как правило меньше секунды).

При желании, можно поверх rabbitmq устроить rpc, но там всё равно будет более высокая нагрузка на железо, чем если бы напрямую происходил вызов.

Лучше возвращать какой-то код ошибки (можно несколько слов. Главное чтобы они никогда не менялись и значили одно и то же) и дополнительную информацию (например id не найденного объекта, роль, которой не хватило, дополнительные коды, и тд), а на фронте по этому коду находить человеческое описание и наполнять его дополнительной инфой.

Но если хочется облегчить жизнь фронту (и усложнить бэку), язык на сайте только русский, и API будет пользоваться только сайтом, то можно на бэке формировать сообщение об ошибке.

Тут нет "более правильного" варианта.
Программная инженерия - это всегда про компромисс.

Я бы выбрал вариант с уже имеющейся базой данных, тк это:
1. Уже проверенное решение
2. Это решение очень простое и понятное
3. Оно не подразумевает усложнение инфраструктуры
4. Оно точно устроит тебя по производительности.

Зависит от того что именно за данные (для какой цели) будут передаваться и между кем и кем.
Rest как и любой другой синхронный метод взаимодействия несёт плюсы:
+ Сравнительно быстрая реакция на запрос и ответ. (как правило от запроса до получения ответа менее секунды)
+ Очень прост в использовании, нет никаких проблем с поддержкой на клиенте
+ Очень простая инфраструктура (в минимальном варианте она не нужна вообще)
+ Всё хорошо изучено. Та же аутентификация и авторизация очень легко реализуется в рамках http.
+ Достаточно легко разрабатывать и тестировать
+ Есть grpc и openapi - нет никакой проблемы с документированием такого API.
+ В http запрос с каким-нибудь multipart form data может спокойно быть размером в десятки мегабайт, а может и больше - полезно при загрузке файлов.
И минусы:
- Не понятно что делать, в случае недоступности ответной стороны
- При неправильной реализации клиента (политики ретраев) - можно легко заддосить сервер

Всякие разнообразные брокеры сообщений тоже имеют свои плюсы:
+ Строгая очерёдность обработки данных (событий) из коробки
+ В случае недоступности ответной стороны - брокер у себя может хоть несколько дней держать данные
+ Все политики ретраев реализуются на стороне брокера
+ Если это rabbit, то можно разные сложные механики рассылки и маршрутизации реализовать
+ Если это кафка или какой-то другой лог, то можно вычитывать события повторно

Но есть и минусы:
- Инфраструктура обычно сложнее
- Достаточно большие задержки
- Использовать можно будет только у себя внутри - внешнему клиенту (браузер, мобильное приложение, публичный API) такое дать не получится.
- Сложнее разграничивать в правах.
- Сложно разрабатывать и тестировать. На примере той же кафки - подключиться к топику и записать в него что-то через гуй - это отдельный челендж.
- Запросы должны быть небольшими (сотни кб)

Выбирай интересующую тему:
- Методологии
- Менеджмент
- Аналитика
- Тестирование
- Разработка
- Эксплуатация
- Проектирование

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

Где-то на одном из внутренних слоёв находится интерфейс для доступа к данным (репозиторий)
А какой-нибудь из внешних слоёв этот интерфейс реализует.

Но насколько я понимаю, HTTP-связь между клиентом и сервером для многопользовательской игры совершенно некорректна.

Зависит от того, что это за игра. Если это какой-то онлайн-шутер, то да, конечно это будет некорректно, но для какой-нибудь пошаговой стратегии - это будет вполне допустимо.

Socket.io и SignalR сделаны поверх websocket, который является расширением для HTTP и построен поверх TCP.
Lidgren network сделан поверх UDP и сейчас активно не поддерживается.

Прежде чем определить, какой именно тебе протокол и подход будет применим тебе нужно ответить на следующие вопросы:
1. Какие именно данные (сообщения) нужно передавать
2. Сколько их будет генерировать один клиент
3. Сколько клиентов должен держать сервер в рамках одной игровой сессии.
4. Какие задержки допустимы для каждого из типов сообщений.
5. Как себя должна вести игра при потере каких-то сообщений и как ты можешь попробовать их компенсировать
6. Клиентом для тебя является браузер или же десктопное/мобильное приложение, или всё сразу.

После всего этого ты сможешь определить, какой протокол тебе допустим - это будет http, вебсокеты, или вообще что-то кастомное поверх UDP или TCP.
Причём для разных типов сообщений ты можешь использовать разный транспорт. Например, для передачи информации о покупках на внутриигровом рынке ты вполне можешь использовать http, а для передачи уведомлений об этих покупках - websocket, а для передвижений персонажей и их действий во внутриигровом мире - UDP, а для загрузки информации о мире и самих игроках - TCP.

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

Логика приложения - всё что связано с взаимодействием с пользователем. Кнопки, формы, итд.

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

Нет. Кнопки - это логика пользовательского интерфейса. Бизнес-логика - то, что за этими кнопками на самом деле стоит.