Проектирование архитектуры сервиса

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

Постановка задачи

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

Примеры команд бота для создания дел:

  1. /1h уйти за хлебом - через час нужно сходить за хлебом
  2. /2m помытся - через 2 месяца нужно помытся

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

Так-же есть команда /closest - выводит ближайшие дела.

База

В базе будет 2 модели:

Task
    id: int
    user_id: int
    text: str - описание дела
    todo_datetime: datetime - срок выполнения дела
    ping_datetime: datetime - срок, когда нужно пингануть пользователя
TaskProducer:
    id: int
    user_id: int
    cron_expression: str
    next_create_task_datetime: datetime - когда в следующий раз нужно содать задачу

В базе будут реплики.

Обработка данных

Далее нужны процессы для обработки данных.

  1. Производитель задач. Под транзакцией достает несколько TaskProducer из базы, для которых настало время создавать задачи, создает задачи, обновляет у TaskProducer следующее время создания задачи.
  2. Отправитель задач. Достает из базы задачи, про которые пора напомнить пользователю и кладет их в очередь. Для удобства назовем очередь TASKS_TO_DO
  3. Cоздаватель Task-ов и TaskProducer-ов Читает очередь (не ту которая в предыдущем пункте, а другую) и достает оттуда данные о Task и TaskProducer которые нужно создать, и создает их. Назовем очередь TASKS_TP_TO_CREATE (TP - сокращение от TaskProducer)

Так-же понадобистя API с простыми GET ручками. В текущей версии бота это одна ручка на получение ближайших дел, но в будущем конечно могут появится другие.

Взаимодействие с Telegram

Теперь обработчики сообщений

  1. Отправитель сообщений Читает очередь TASKS_TO_DO и отправляет сообщения в телегу. Подтверждает получение в очереди только после успешной доставки сообщения в телеграме.
  2. Получатель сообщений Получает сообщение от пользователя. Валидирует его корректность. Если сообщение на получение информации (то есть команда closest) - идет в API и возвращает информацию пользователю в чате. Если API недоступно пишет об этом пользователю. Если недоступно API телеграма - ничего не делает. Некритично если пользователь не получит ответ на запрос. Если сообщение на создание дела кладет его в очередь TASKS_TP_TO_CREATE

Доска на miro со схемой


Ответы (0 шт):