Задача 1. Интернет-магазин и склад
Вводная
Компания запускает интернет-магазин. Заказы принимает сервис магазина, а информацию об остатках хранит отдельный складской сервис.
Разработчики решили разделить ответственность между двумя backend-приложениями.
Backend №1 — Shop Service
Отвечает за:
- создание заказа;
- просмотр заказов;
- получение статуса заказа.
Сущность:
{
"id": 1,
"productId": 15,
"quantity": 2,
"status": "NEW"
}
API:
POST /orders
GET /orders
GET /orders/{id}
Backend №2 — Warehouse Service
Отвечает за:
- хранение остатков;
- резервирование товара;
- списание товара.
Сущность:
{
"productId": 15,
"stock": 100
}
API:
GET /products/{id}/stock
POST /reserve
Взаимодействие
После создания заказа Shop Service вызывает:
POST /reserve
в Warehouse Service.
Если товара достаточно:
{
"success": true
}
Статус заказа меняется на:
CONFIRMED
Если товара нет:
REJECTED
Что изучается
- REST API;
- HTTP-коды;
- JSON;
- взаимодействие сервисов;
- обработка ошибок.
⸻
Задача 2. Сервис доставки и сервис заказов
Вводная
После подтверждения заказа необходимо организовать доставку.
Компания выделяет отдельный сервис логистики.
Backend №1 — Order Service
Хранит:
{
"id": 100,
"customer": "Alex",
"status": "READY_FOR_DELIVERY"
}
API:
POST /orders
GET /orders/{id}
Backend №2 — Delivery Service
Создает доставки.
Сущность:
{
"deliveryId": 1,
"orderId": 100,
"status": "CREATED"
}
API:
POST /deliveries
GET /deliveries/{id}
Взаимодействие
Order Service вызывает:
POST /deliveries
Передает:
{
"orderId": 100
}
Получает:
{
"deliveryId": 1
}
После этого сохраняет связь заказа и доставки.
Что изучается
- API между микросервисами;
- DTO;
- интеграционные ошибки;
- retry-механизмы.
⸻
Задача 3. Пользователи и сервис авторизации
Вводная
Компания разделяет бизнес-логику и безопасность.
Авторизация вынесена в отдельный сервис.
Backend №1 — User Service
Отвечает за пользователей.
API:
POST /users
GET /users/{id}
Backend №2 — Auth Service
Отвечает за:
- логин;
- JWT;
- проверку токена.
API:
POST /login
POST /validate
Логин
Запрос:
{
"email": "user@mail.com",
"password": "123456"
}
Ответ:
{
"token": "jwt-token"
}
Проверка токена
POST /validate
Ответ:
{
"valid": true,
"userId": 15
}
Взаимодействие
User Service перед выполнением защищенного действия обращается к Auth Service.
Что изучается
- JWT;
- авторизация;
- API Gateway;
- безопасность API.
⸻
Задача 4. Платежный сервис и сервис подписок
Вводная
Сервис продает платные подписки.
Платежи вынесены в отдельный backend.
Backend №1 — Subscription Service
Хранит:
{
"userId": 1,
"plan": "PRO",
"active": false
}
Backend №2 — Payment Service
API:
POST /payments
GET /payments/{id}
Сценарий
- Пользователь покупает подписку.
- Subscription Service вызывает Payment Service.
- Если платеж успешен:
{
"status": "SUCCESS"
}
- Подписка активируется.
Дополнительное условие
Реализовать webhook:
POST /webhook/payment
Платежный сервис сам уведомляет сервис подписок о завершении платежа.
Что изучается
- webhooks;
- callback API;
- асинхронное взаимодействие;
- идемпотентность.
⸻
Задача 5. Аналитика и сервис событий
Вводная
Компания хочет собирать статистику действий пользователей.
Для этого создается отдельный аналитический сервис.
Backend №1 — Main Service
Принимает действия пользователей:
{
"userId": 10,
"action": "VIEW_PRODUCT"
}
Backend №2 — Analytics Service
API:
POST /events
GET /stats
Взаимодействие
Main Service отправляет события:
POST /events
{
"userId": 10,
"action": "VIEW_PRODUCT",
"timestamp": "2026-06-04T10:15:00Z"
}
Analytics Service агрегирует статистику.
Что изучается
- событийная архитектура;
- API для передачи событий;
- нагрузка;
- проектирование контрактов.
⸻
Продвинутая задача
Система бронирования авиабилетов
Backend №1 — Booking Service
- поиск рейсов;
- создание бронирования;
- управление заказом.
Backend №2 — Ticket Service
- выпуск билетов;
- оплата;
- отмена билетов.
Требования
- JWT авторизация;
- OpenAPI/Swagger;
- versioning API (/api/v1);
- correlation-id;
- retry;
- логирование запросов;
- webhook уведомления;
- rate limiting.
Эта задача позволяет пройти почти весь цикл проектирования реального API между двумя backend-сервисами.