Задача
Покупателю нужен предсказуемый путь от каталога до подтверждённого заказа, а поставщику — управление товарами, остатками и входящими заказами. При этом конкурентные запросы не должны приводить к продаже одного остатка дважды.
Назад к проектам
Retail Procurement API
Backend-приложение для закупок между покупателями и поставщиками. Проект объединяет каталог, корзину, оформление заказов, импорт прайс-листов, роли пользователей и фоновые операции.
- Контекст
- Дипломный backend-проект
- Домен
- B2B-закупки и управление заказами
- Основа
- Django · DRF · PostgreSQL
PROBLEM & CONSTRAINTS
Заказ — это не просто создание строки в базе.
Ключевая сложность проекта находится на границе каталога, корзины, остатков, ролей и длительных фоновых операций.
Ограничения
- Проверка и списание остатков должны выполняться атомарно.
- Импорт YAML-прайсов, уведомления и обработка изображений не должны блокировать HTTP-запрос.
- Покупатель, поставщик и администратор работают с разными правами и сценариями.
- Кэш каталога должен инвалидироваться при изменениях, влияющих на выдачу.
ARCHITECTURE
Синхронный путь покупки отделён от фоновой работы.
DRF принимает запрос, сервисный слой управляет бизнес-транзакцией, PostgreSQL защищает остатки, а Redis и Celery обслуживают кэш и длительные задачи.
- transaction.atomic
- select_for_update
- cache invalidation
- background tasks
PURCHASE FLOW
Оформление заказа проходит через явную бизнес-транзакцию.
Сервисный слой собирает проверки в одном месте и не позволяет контроллеру стать контейнером бизнес-логики.
Каталог и корзина
Покупатель фильтрует каталог, добавляет товары в корзину и изменяет количество позиций. Каталог может обслуживаться из Redis-кэша.
Проверка прав и входных данных
DRF проверяет аутентификацию, роль пользователя, состав корзины и корректность запроса до запуска транзакции.
Блокировка остатков
Сервис оформления заказа открывает transaction.atomic и получает строки остатков через select_for_update, исключая конкурентное списание.
Создание заказа
После успешной проверки остатки списываются, заказ и позиции сохраняются как единое согласованное изменение.
Фоновые действия
Email, импорт прайс-листов и обработка изображений передаются Celery-воркеру и не увеличивают время ответа API.
KEY DECISIONS
Надёжность заказа обеспечивается структурой кода и БД.
Инструменты выбраны под конкретные риски: конкуренцию за остатки, длительные операции и повторное использование бизнес-правил.
Сервисный слой для заказа
Оформление вынесено из view в отдельный сценарий, где собраны проверки, блокировки и изменение связанных сущностей.
Блокировки PostgreSQL
transaction.atomic и select_for_update защищают остатки в момент конкурентного подтверждения корзин.
Celery для длительной работы
Импорт YAML, email и обработка изображений выполняются вне request-response цикла.
Redis-кэш каталога
Часто читаемые данные кэшируются, а изменения товаров и категорий запускают явную инвалидацию.
QUALITY & DELIVERY
Критические пользовательские сценарии закреплены тестами.
Проект проверяет не только отдельные endpoints, но и интеграционный путь покупки от аутентификации до оформления заказа.
Аутентификация, throttling, каталог, корзина, оформление заказа и интеграционный сценарий покупки.
Схема API генерируется через drf-spectacular и доступна в двух форматах документации.
Контейнеризированное окружение и автоматические проверки обеспечивают воспроизводимый запуск.
LIMITS & NEXT STEPS
Функциональность завершена, но продуктовые контуры можно расширять.
В кейсе отделены реализованные механизмы от задач, которые остаются следующим уровнем развития.
История статусов и аудит действий
Для полноценной операционной трассировки нужны отдельная история переходов заказа и журнал действий пользователей.
Скидки и промокоды
Ценообразование пока не выделено в самостоятельный расширяемый модуль правил и кампаний.
Нагрузочные сценарии
Следующий шаг — воспроизводимые тесты конкурентного оформления и поведения каталога под нагрузкой.
RESULT
Проект показывает backend как набор согласованных бизнес-сценариев.
Главный результат — не количество endpoints, а явное разделение HTTP-слоя, транзакционного заказа, кэша и фоновых задач.
- Конкурентные изменения остатков должны защищаться на уровне транзакции и базы данных.
- Длительные операции не должны становиться частью пользовательского HTTP-ответа.
- Сервисный слой полезен там, где один сценарий изменяет несколько связанных сущностей.
SOURCE CODE
Код, тесты и документация доступны в репозитории.
README содержит быстрый старт, API-сценарии, структуру проекта и команды запуска через Docker Compose.