Иван Шумов

Всегда нужно использовать транзакции

Во-первых AWS в тегах тут не при чем совсем. Это разные сервисы. А во-вторых если Amazon говорит что вы не удовлетворяете их требованиям то никак, простите. Туда не всех пускают

Нормализуй базу, вынеси даты в отдельную таблицу и работай уже с ней в нормальном формате, с join'ами. А не вот этот весь треш.

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

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

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

Вообще:
- выделите сущности системы (Entities of Domain Model хотябы)
- составьте список ролей и действий, которые они делать (UseCase)
- вот тут начнет проясняться

По быстрому это на фриланс, а по нормальному это идти читать официальную документацию по api телеги

Без разницы. Что эти три продукта, что репы от cloud providers. Они весь базовый функционал делают одинаково.

Что касается автоматизации то мне тут немного смешно слышать про gitlab ci по тому как в нормальных проектах все поставлено на нормальные pipelines - Azure devops, aws code star, а так же всеми любимые Jenkins и teamcity.

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

Поставь за ним haproxy и маршрутизируй сколько влезет

Во-первых нельзя, а во-вторых не нужно

Документацию писать надо) вот и весь секрет