Melkij

Обратите внимание, что в HTML нет method PUT.
https://www.w3.org/TR/html5/forms.html#attr-fs-method

The invalid value default for these attributes is the GET state.

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

Раз они однотипные - то может и задачу они решают однотипную?
Может, вам нужен паттерн factory и в контроллере и будет только use фабрики?

Конечно, Макконнелл "Совершенный код",
Мартин "Чистый код"
"Рефакторинг" Фаулера

"Приемы объектно-ориентированного проектирования" Э. Гамма

Поскольку в списке mysql - High Performance MySQL обязателен к прочтению
Отдельно рекомендую "Регулярные выражения" Дж.Фриддла, отлично вправляет мозг по регуляркам.

По базам в целом:
короткая "Architecture of a Database System" J. M. Hellerstein, M. Stonebraker and J. Hamilton расскажет об общих подходах построения СУБД
Bill Karwin SQL_Antipatterns - как не надо писать SQL. А вот, кстати, отличный материал как надо писать, но не книга: use-the-index-luke.com

Это всё вполне можно читать в порядке отдыха.

Фундаментальные, которые уже идут заметно тяжелее:
"Transactional Information Systems" Weikum, Vossen - монументальная теория транзакционной обработки
"Алгоритмы. Построение и анализ" Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн - про основные алгоритмы. Всё библиотечное, но полезнейшая весь для понимания обычно скрытой машинерии и для прохождения собеседований.

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

Сделать редирект куда-нибудь в другое место. Например, на ту же самую страницу, но без параметра в url.

SSH конектится что с сервака на десктоп, так и обратно

Внимание, вопрос: под каким пользователем?
Потому что плейбук вы с весьма неясной целью запускаете через sudo. А у рута в таком случае ключи настроены?

Вообще не надо в /etc/ansible лезть. Заведите себе в любом месте директорию и в ней размещайте всю информацию для ansible. ansible-playbook не нужны рутовые права для своего запуска. Ему нужен только доступ на целевые хосты и возможность орудовать там.

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

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

И пусть. Нормально сделанной базе плюс-минус лям пользователей - не вопрос.

Тоже самое с комментариями, легко сделать скрипт чтобы оставлял с разных ботов в разных топиках комментарии с рекламой.

С этим сложнее. Если есть пользовательский контент - то сначала необходимы люди, которые будут его модерировать (не забудьте сделать внятный инструмент модератора для поиска и удаления пачкой комментариев по шаблону). Антиспам автоматика не исключает необходимости в людях, которые будут проверять вручную. Вы видели спам на stackoverflow? А попадается и там.
И капча, разумеется, не панацея тоже.

primary key нужен всегда.
Если по логике вашего приложения одному user_id может соответствовать только один пользователь в каждом service_id - то PK на первые два поля.
Если несколько - то pk на 3 поля.

Порядок полей при указании PK таблицы связей важен. Для mysql/innodb очень важен, т.к. таблица кластеризована по PK и любое обращение по вторичному ключу влечёт поиск по PK (кроме покрывающих индексов). Порядок выбирайте исходя из наиболее частых запросов к таблице, чтобы максимум запросов могло идти по первичному ключу.

Есть ли в распараллеливании запросов рациональное зерно?

Есть, если треды не дерутся за одно и те же ресурсы. Например, ходят в физически разные кластеры БД.

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

Или вы неверно описали наблюдаемый результат или же параллельное выполнение медленнее в 2 раза и дальше ухудшается при конкурентной нагрузке.

На каком-то этапе параллельные запросы также выстраиваются в очередь.

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

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

Что подтверждает диагноз. Ресурсов для параллельного выполнения нет.

Поскольку вопрос затрагивает субд и вы не называете, что там происходит - самое очевидно - вы упёрлись в диски. Возможно даже в механические диски. Добавление новых io задач на диски ожидаемо и очень сильно замедляет весь остальной io.