async-architecture

async-architecture

ДЗ 0 до курса (мега-тупое решение)

Что тут в целом

Выделил два сервиса - Tasks, в котором будут храниться текущее состояние наших задач и пользователи, и Accounting, в котором будут храниться лог операций с задачами и лог выплат.

Общение между ними будет происходить асинхронно через кафку, но для одной операции сервиса Accounting (отправка уведомлений на почту) придется выполнить синхронный запрос в Tasks, чтобы получить имейлы. Можно их на стороне Accounting сохранять в кэш или писать имейл в таблицу с логом.

На стороне Tasks будет процесс, производящий запись в кафку, на стороне Accounting будут консьюмеры, процесс для агрегации лога операций с задачами в лог выплат, процесс для произведения выплат и процесс для уведомления по емейлу.

На стороне сервиса Tasks реализуем 5 ручек для отрисовки и функионирования дашборда таск трекера + 1 ручка для аналитики (самая дорогая задача).

На стороне сервиса Accounting реализуем 4 ручки для шаборда аккаунтинга, одну из них заюзаем для аналитики (сколько бизнес заработал по дням) + 1 ручка чисто для аналитики (количество попугов в минусе).

Узкие места

• Их нет
• Упадет сервис задач - отвалится часть админки и весь таск трекер, для каких то попугов не будут уходить письма о выплатах, как сервис поднимется - придут. Упадет сервис аккаунтинга - отвалится другая часть админки и весь аккаунтинг.
• Отрубится кафка - таск трекер продолжит работать, но попуги могут не получить плату за всю проделанную работу, потому что аккаунтинг не будет знать об изменениях по задачам. Как кафка поднимется - сервис задач докинет в аккаунтинг данные и оставшиеся выплаты должны пройти.
• Если упадет база данных, то будем пятисотить на ручках. В случае Tasks не будут двигаться задачи в принципе и добавляться списания, в случае Accounting не будет производится запись из кафки и списания. Наверно Accounting стоит чинить быстрее, чтобы партиции в кафке не росли.
• Отвалится кэш - будем ддосить Tasks из Accounting во время отправки писем.
• Возможно прилетят дубли из кафки - через uuid можно защититься кажется.

Что улучшить

• Не понял как авторизация работает и откуда берутся пользователи в принципе.
• Ручки аккаунтинг возможно можно как-то упростить/ускорить, добавив таблицу с балансом для каждого попуга, но думаю сильно сложнее станет подсчет и запись денег - станет проще ошибиться.
• Может быть сделать отдельный сервис для пользователей.

ДЗ 1

Разбиение требований

Авторизация

• Пользователь входит в систему:

  Actor: unlogged account Command: log in Data: credentials Event: account.logged_in

• Изменение данных пользователя / создание нового аккаунта

  Actor: account / admin account Command: change account data / create account Data: account_data(email, ...) Event: account.updated / account.created

Задачи

• Новые таски может создавать кто угодно

  Actor: account Command: create task Data: task_description Event: task.created

• Создать задачу не заасайненую на пользователя нельзя

  Actor: task.created Command: assigne task Data: task_id Event: task.assigned

• При нажатии кнопки «заассайнить задачи» все текущие не закрытые задачи должны быть случайным образом перетасованы между каждым аккаунтом в системе

  Actor: admin / manager account Command: reassign tasks Data: - Event: task.assigned

• Каждый сотрудник должен иметь возможность отметить задачу выполненной

  Query: get account tasks Actor: account Command: complete task Data: task_id Event: task.completed

• Каждый сотрудник должен иметь возможность видеть в отдельном месте список заассайненных на него задач

  Query: get account tasks Actor: account

Аккаунтинг

• У обычных попугов доступ к аккаунтингу тоже должен быть. Но только к информации о собственных счетах (аудит лог + текущий баланс)

  Query: get user audit log Actor: account

• У админов и бухгалтеров должен быть доступ к общей статистике по деньгами заработанным (количество заработанных топ-менеджментом за сегодня денег + статистика по дням)

  Query: get all users audit log Actor: admin / accountant account

• У счёта должен быть аудитлог того, за что были списаны / начислены деньги

  Actor: task.assigned / task.completed Command: create audit log Data: task_id, user_id, ammount Event: audir_log_record.created

• Цены на задачу определяется единоразово, в момент появления в системе

  Actor: task.created Command: estimate task Data: task_id Event: task.estimated

• В конце дня необходимо считать сколько денег сотрудник получил за рабочий день / в аудитлоге всех операций аккаунтинга должно быть отображено, что была выплачена сумма

  Actor: end_of_day_event Command: create payment log Data: user_id Event: payment_log_record.created

• В конце дня необходимо отправлять на почту сумму выплаты

  Actor: payment_log_record.created Command: send email Data: user_email, other_meta Event: email.sent

Аналитика (Подразумевается сделать на базе аккаунтинга)

• Нужно указывать, сколько заработал топ-менеджмент за сегодня

  Query: get all users audit log Actor: admin account

• Нужно указывать, сколько попугов ушло в минус

  Query: get users negative payment log Actor: admin account

• Нужно показывать самую дорогую задачу за день, неделю или месяц

  Query: get most expensive task in period Actor: admin account

Модель данных, доменов, их связей

Аналитику планирую сделать надстройкой над сервисами задач и аккаунтинга, но в случае необходимости можно наверно настроить репликацию баз и сделать отдельный сервис.

Бизнес-события системы

• account.logged_in

  Producer: auth Consumers: -

• task.assigned

  Producer: tasks Consumer: accounting

• task.completed

  Producer: tasks Consumers: accounting

• task.estimated

  Producer: accounting Consumers: accounting

• payment_log_record.created

  Producer: accounting Consumers: accounting

• audit_log_record.created

  Producer: accounting Consumers: -

• email.sent

  Producer: accounting Consumers: -

CUD-события системы

• account.created, account.updated:

  Producer: auth Consumers: tasks, accounting

• task.created, task.updated

  Producer: tasks Consumers: accounting