Иван Шумов, Вопрос, к сожалению, не содержит достаточно конкретной информации о реализации. Если суть проблемы в том, чтобы не позволить одному и тому же пользователю дважды изменить сумму, то должно быть достаточно SELECT ... FOR UPDATE (приведет к блокировке других операций чтения для данных строк с FOR UPDATE) по id пользователя + id того кто выполнил запрос, а затем выполненить операцию по увеличению суммы. Порядок исполнения транзакций, судя по задаче, не важен.
Максим Компаниец, явно nginx тут не виноват и нет смысла мучать его. Либо вовсе временно уберите его из цепочки.
В логи докера по умолчанию сыпятся обычно только из stdout. Нужно логи каждого сервиса писать туда, либо в файл/каталог примонтированный через volume в файловую систему хоста. Без логов можно продолжать угадывать очень-очень долго. Bad Gateway означает что ваш бекенд вернул ошибку
А ч о у вас там с числом воркеров в gunicorn? Не выжираются ли все доступные процессы?
Другой вариант - какие-то из запросов вводят ваш код в бесконечный цикл, что, опять же, приводит к выеданию всех доступных потоков в gunicorn.
В зависимости от OS, есть способы автоматизированной установки (autoinstall у Ubuntu, к примеру). Там можно на этапе установки указать в том числе и разбиение диска.
Для подготовки эталонного образа, а так же для создания новых машин из эталонного можно использовать hashicorp packer.
