Как продумать грамотную архитектуре

zybik

В общем, коротко насколько можно суть "проекта":

Сбор событий и коэффициентов с pinnacle(а именно с одного "вида/игры" в киберспорте). И дальнейшего отслеживания изменения коэффициентов для каждого матча с заданными интервалами(то есть наступило время проверки, скрапер идет собирает информацию) до выхода в лайв(после отслеживание не ведется). Матчей не так много, линии собираются тоже не все, только основные.

Реализовано с асинхронным подходом, но есть нюанс, работа с postgresql без специальных драйверов, поддерживающих asyncio(Все методы в DatabaseOperations помечены как async, но внутри используют синхронные операции с БД?)

Самый малый интервал проверки 1 минута. И то за 10 или 15 минут до матча.

Помучал иишку, и я так понял, что асинхронно работать с БД нужно, когда планируется высокая частота проверок и запросов с записями(например, в лайве).
Вопросы такие:

Стоит ли игра свеч, чтоб переписывать код под асинхронное взаимодействие с БД?
Как повлияет на масштабируемость в будущем оставление в текущем виде?
К примеру, я хочу прикрутить статистику, которую будет собирать отдельный ботик, а также добавить отслеживание коэффициентов с пары других контор, под каждую свой ботик. (Тут кстати тоже возникает интересный вопрос, как это все грамотно совместить)

Хочется изначально все продумать наперед, выявить узкие места и потенциальные проблемы. Но опыта скажем так, его нет. Куда копать, на что обратить внимание?
Одна аишка советует:

Для добавления статистики и других букмекеров я бы предложил микросервисную архитектуру:

Каждый бот - отдельный процесс
Общая база данных
Общий конфиг
Возможно, очередь сообщений (RabbitMQ) для коммуникации

Другая:

Каждый бот собирает данные независимо и пишет их в БД (лучше через очередь, например, Redis, Kafka или даже простую таблицу в PostgreSQL).
Главный процесс читает и агрегирует данные по запросу или с определённой периодичностью.
Можно использовать отдельную таблицу для кэширования актуальных данных, чтобы не нагружать базу частыми запросами.
Redis или PostgreSQL в качестве брокера сообщений будет нормальным решением.

kvakirsanov

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

Если говорить о сферической задаче получения данных от разных источников, и аналитике, то хорошо в этом работает микросервисная архитектура, общая шина обмена данных вроде ampq и pub/sub модель обмена данными.