Запуск

Конфиг через deploy/.env.

Команда запуска:

source ./deploy/.env && docker compose --file=./deploy/docker-compose.yaml up --build

Дополнительные команды

В Makefile.

Тестирование

Команда запуска:

go test market-info-storage/internal/controllers/v1/orderbook market-info-storage/internal/controllers/v1/orderhistory

Заметки

Bid, Ask

На вход SaveOrderBook подается массив обьектов DepthOrder, а хранить его требуется в виде разделения на Bid и Ask ордера, поэтому я исходил из предположения, что первая половина это Bid ордера, а вторая - Ask ордера.

Базы данных

Для таблицы order_books не вижу смысла использовать ClickHouse в контексте текущих операций, а именно частое обновление и получение конкретной строки. Также мне сложно представить аналитику, которую можно было бы проводить с стаканами цен разных пар. Поэтому данная таблица реализована мной в Postgres.

Также в таблице order_books можно за primary key взять (exchange, pair) чтобы не поддерживать лишний индекс по id(который не участвует в получении данных), однако на случай появления связей с другими таблицами(чтобы не хнарить foreign key в виде двух строковых значений вместо одного int или не менять primary key на id) я оставил id как primary key и добавил индекс для (exchange, pair).

Ручки

SaveOrder, GetOrderHistory: правильным с моей точки зрений URI был бы /clients/{client-id}/order-history, однако на вход мы получаем клиента с 4 полями без id, их все запихивать в путь не хочется, также плохо оставлять URI просто в виде /order-history и передавать клиента в теле запроса т.к. в этом случае URI не обозначает конкретный ресурс, а обьеденяет в себе множество независимых ресурсов. Поэтому в качестве компромиса все поля клиента передаются в виде query аргументов.

Типы данных в struct для запросов

Некоторые поля запросов имею тип указателя т.к. библиотека binding которая проверяет условие "required" не различает отсутствие поля и нулевое значение у некоторых типов.