DarkTM

Начать стоит с того, что все вами перечисленное к безопасности относится только косвенно.

А теперь по пунктам:
1. Полностью защищенных сайтов не бывает.
2. Основная защита сайтов, это защита от мамкиных хакеров и не более. Серьезные дяди без пункта 3, вас взломают 100% вероятностью, как бы вы не изворачивались.
3. Для серьезной защиты ресурса от взлома нужно: иметь внутреннюю или внешнюю программу пинтеста (т.е. своих хакеров, которые будут пытаться взломать и искать дыры), команду по сетевой безопасности, команду по общей безопасности. Без этого, профессионалы которым вы понадобитесь, ломанут вас с гарантией. Со всем перечисленным, фифти-фифти, зависит уже от уровня ваших спецов, и тех что сидят по ту сторону.
4. Даже если кто-то из местных спецов, иб ответит, в чем я сильно сомневаюсь, ответ вы получите ровно тот же, что вам уже дали выше, если не еще более нелецеприятный. Причина проста, вы тратите время людей.
5. Что бы даже в кратце расписать основные типа и основные методы противодействия, нужно потратить от 8 до 10 часов своего времени, вы его людям вряд ли оплатите.
6. Пункт 4 вам обеспечен по тому, что в интернете, если пользоваться гуглом все уже есть. И вы можете потратить сове время и не тратить чужое. И прийти сюда уже с конкретным вопросом, по конкретной теме. Вот вам для затравки так сказать, перечислены самые популярные типовые атаки:
https://bool.dev/blog/detail/common-and-not-common...
https://itsecforu.ru/2020/02/11/%F0%9F%92%89-9-%D0...

если мало по вышеприведенным ссылкам и хочется совсем заморочаться, то идем сюда https://owasp.org/ и наслаждаемся тысячами уязвимостей и способов которыми вас мог хакнуть, и что вы можете закупорить.

https://pm2.keymetrics.io/docs/usage/application-d...

Пример для python:

{
    "apps": [{
        "name": "app_name",
        "script": "/the/app/path/my_app.py",
        "args": ["-c", "my_config.prod.json"],
        "instances": "1",
        "wait_ready": true,
        "autorestart": false,
        "max_restarts": 5,
        "interpreter" : "/path/to/venv/bin/python",
    }]
}

мой совет просто почитайте про pm2 и по экспериментируйте с ним.

По-моему, тут очевидный 1 вариант, выпилить с проекта города в отдельную сущность, со своим api, и отдавать города и адреса.
Во втором и третьем варианте, сразу видится проблема DRY, если в нескольких контекстах повторяются города и методы для них.
Вообще это азы... вроде как... хотя может только и для меня, но если у вас в проекте, что-то повторяется в нескольких местах, то это нужно вынести в отдельную сущность, работать как с отдельным модулем со своим API. Проще написать единое API, для всех городов и обработчик внутри каждого домена которому нужна эта сущность, и дополнять по необходимости, чем реализовывать одно и тоже в каждом.

Правильная архитектура, она сама себя документирует, так как отражает происходящие процессы. Ведение документации закладывается изначально в проект. В каждом языке есть свой инструмент для автоматической генерации док. Хотя правильно сразу делать гайдлайн + общая модель всех бизнес процессов, плюс нарезка на микросервисы.
В вашем случае - уже поздно пить боржоми когда печень сдохла. Так как проект вышел из под контроля и ситуации, когда есть хоть кто-то, кто может описать работу вашего сервиса. И вам написали один из двух выходов - переписывать с нуля. Второй выход - форкать, садить человек пять и пусть разбираются в коде и как оно работает, заодно и документируют. Других средств просто нет.
Хотя нет вру, вру. есть. Написать нейронку, распарсить код, сделать AST, скормить нейронке и пусть задокументирует. Стоить это будет думаю больше чем весь ваш проект в принципе.