Накопительная система лояльности

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

Общие ограничения и требования

• POST /api/user/register — регистрация пользователя;
• POST /api/user/login — аутентификация пользователя;
• POST /api/user/orders — загрузка пользователем номера заказа для расчёта;
• GET /api/user/orders — получение списка загруженных пользователем номеров заказов, статусов их обработки и информации о начислениях;
• GET /api/user/balance — получение текущего баланса счёта баллов лояльности пользователя;
• POST /api/user/balance/withdraw — запрос на списание баллов с накопительного счёта в счёт оплаты нового заказа;
• GET /api/user/withdrawals — получение информации о выводе средств с накопительного счёта пользователем.

Общие ограничения и требования

• хранилище данных — PostgreSQL (Docker);
• типы и формат хранения данных (в том числе паролей и прочей чувствительной информации);
• клиент может поддерживать HTTP-запросы/ответы со сжатием данных;
• клиент не обязан делать запросы соответственно нижеизложенной спецификации API;
• формат и алгоритм проверки аутентификации и авторизации пользователя (JWT);
• номера заказов уникальны и никогда не повторяются;
• номер заказа может быть принят в обработку только один раз от одного пользователя;
• номер заказа может не иметь никакого начисления;
• вознаграждение начисляется и тратится в виртуальных баллах из расчёта 1 балл = 1 единица местной валюты.

Основные моменты и особенности реализации

• Особенность данной реализации заключается в том, что в основе обработки поступающих данных находятся два паттерна: Pipeline и Worker Pool.

• Запросы поступают в микросервис и обрабатываются http сервером - Gin (высокопроизводительный фреймворк для Go), который приземляет их на соответствующие points.

• В момент поступления данных происходит инициализация конвейера обработки данных реализованного на основание двух паттернов Pipeline и Worker Pool. Обработка данных разбита на отдельные процессы (pipe-ы). Такое распределение в процессе разборки дает преимущество в том, что позволяет детализировать процесс обработки и добавлять новые не переживая повредить ранее реализованные. Также ранее реализованые процессы можно использовать при создании новых Points включая их в цепочку обработки. Данная реализация похожа на паттерн Chain of Responsibility. Но лишена жесткой связки и позволяет вклинится между процессами например: для рассылки результатов промежуточной обработки данных с помощью брокера сообщений RabbitMQ; для обращения к другим микросервисам по gRPC; и тп.

• Передача данных происходит по каналам. В результате входящий канал одного процесса это исходящий канал предыдущего (input/output).

• На всех этапах обработки данных реализована распределенная трассировка при помощи Jaeger, что делает процессы полностью прозрачными по времени выполнения. Это возможно благодаря передачи context во все созданные процессы.

• Также доступно логирование при помощи Zap с различными уровнями.

• В проекте реализовано табличное тестирование с помощью Testify и Gomock, которое покрывает все основные обработчик.
• В проект добавлен gRPC server/client, а также зарегистрированы унарные перехватчики (UnaryServerInterceptor/UnaryClientInterceptor) с помощью, которых объединяем все вызовы при трассировки делая выполнение запроса к сервису еще более прозрачным.