25 марта 2026 года Минцифры вынесло на обсуждение проект закона о почтовой отрасли: АО «Почта России» разрешат продавать лекарства и размещать рекламу на платёжках за ЖКУ, а маркетплейсы обяжут открывать пункты выдачи заказов (ПВЗ) в отделениях связи. Что это значит для выпускника ИТ-специальности? Ровно одно: государство административно создаёт спрос на связку «фармацевтический ретейл + логистика + маркетплейс-платформа» — а значит, появляется реальный, документируемый кейс для ВКР. Ниже — как из этой новости сделать не пересказ статьи, а инженерную работу с архитектурой, метриками и защитой.
Статья лежит на стыке нескольких областей, но для ВКР наиболее защищаемый срез — Backend/Data Engineering: интеграция учётных систем маркетплейса, аптечного контура и сети отделений через API и потоковую передачу событий. Роль, от которой я даю советы, — Архитектор ПО / Системный аналитик: именно эти специалисты проектируют контуры обмена заказами, статусами и товарными остатками между разнородными участниками.
| Элемент анализа | Содержание |
|---|---|
| Основной запрос | омниканальная логистика маркетплейса и ПВЗ в ВКР |
| LSI-запросы | REST/OpenAPI, Kafka и RabbitMQ, паттерн Saga и идемпотентность, C4-диаграмма, BPMN процесса выдачи заказа, PostgreSQL, CDC-репликация, метрики SLA и lead time, OpenTelemetry-трейсинг, ГОСТ 34.602 |
| Реальные вопросы студентов | 1) Где взять данные, если нет доступа к АС «Почты России»? 2) Какой стек оправдан — монолит или микросервисы? 3) Как считать экономический эффект без промышленной нагрузки? 4) Как оформить схемы интеграции по ГОСТ? 5) Что делать, если руководитель требует «новизну», а тема регуляторная? |
| Ключевые сущности | ГОСТ 34.601/34.602, ISO/IEC 25010, C4/UML, OpenTelemetry, метрики поддомена (p95 отклика API, доля отмен по таймауту, MTTR) |
Можно и нужно. Новостной повод — это только «шапка» актуальности в первой главе. Технологическое ядро вы вводите сами: событийная шина между ПВЗ и маркетплейсом, сервис проверки фармацевтических ограничений, кэш остатков. Никто не требует, чтобы регулятор писал за вас архитектуру.
Три легальных источника: открытые датасеты маркетплейсов и тарифов доставки, синтетический генератор заказов (Faker + нормальное распределение по времени суток), нагрузочный профиль из документации k6. Плюс собственный стенд в Docker Compose — этого достаточно для воспроизводимых метрик.
Для бакалаврской ВКР достаточно прототипа на два-три сервиса с подтверждёнными тестами и замером p95. Для магистерской — обязательна валидация на модели нагрузки с обоснованием выбора паттерна консистентности.
C4-уровни 1–2 давайте по ГОСТ 34.602 как «схема функциональной структуры», сценарии выдачи — BPMN с расшифровкой обозначений в приложении. Единый стиль подписей и нумерация по разделам спасают от половины замечаний.
Не пересказывайте новость — цитируйте конкретику: разрешение на продажу лекарств, реклама на платёжных документах, обязательства маркетплейсов по ПВЗ. Дальше формулируйте функциональные требования в терминах ГОСТ 34.602: какие внешние системы обмениваются данными, какие роли у пользователей, какие ограничения по времени реакции. Уместно приложить диаграмму контекста C4 уровня 1: актор «клиент», актор «аптека», актор «оператор ПВЗ», внешние системы «маркетплейс» и «учётная система отделения».
Здесь оправдайте выбор брокера и паттерна. Для сценария «выдача заказа в ПВЗ» хорошо ложится хореографическая Saga: каждый шаг публикует событие, компенсирующая транзакция откатывает резерв. Пример идемпотентной обработки входящего события на стороне сервиса отделения:
// Псевдокод обработчика события order.issued
async function handleOrderIssued(event) {
const key = `issued:${event.orderId}:${event.pvzId}`;
const seen = await redis.set(key, '1', { NX: true, EX: 86400 });
if (!seen) return ack(); // дубль — молча подтверждаем
await db.transaction(async (trx) => {
await trx('shipments')
.where({ order_id: event.orderId })
.update({ status: 'DELIVERED', delivered_at: event.ts });
await trx('audit_log').insert({ entity: 'shipment', payload: event });
});
tracer.span('pvz.delivery.confirmed', { orderId: event.orderId });
return ack();
}
Параллельно постройте BPMN-диаграмму процесса с тремя дорожками: маркетплейс, логистический оператор, окно выдачи. Это снимает 80% вопросов комиссии о том, «где здесь вообще система».
Метрики поддомена берутся не абстрактно, а из целей по ISO/IEC 25010 (производительность, надёжность, сопровождаемость). Минимальный набор: p50/p95 задержки API, доля отменённых операций по таймауту, время восстановления после отказа брокера (MTTR), количество успешных компенсаций Saga. Замеряйте на стенде k6 при профиле «утренний пик выдачи» и сравнивайте с базовым монолитом — это и есть ваша «эффективность».
1. Пересказ новости вместо анализа. Половина работы посвящена «спасению Почты России», а технической постановки нет. Как избежать: новость — только 1–1,5 страницы главы 1, остальное — требования и архитектура.
2. Игнорирование предметной специфики лекарств. Фармацевтический контур требует учёта сроков годности и ограничений на возврат. Если модель данных этого не отражает, комиссия заметит мгновенно. Добавьте атрибуты партии и правила отказа в приёме возврата.
3. Метрики «на глазок». Фраза «система работает быстро» без p95 и профиля нагрузки обнуляет главу 3. Снимайте замеры минимум в трёх прогонах и приводите доверительные интервалы.
Если тема кажется перспективной, но не хватает времени на реализацию стенда, расчёт метрик и оформление — у нас есть формат сопровождения на 120 часов: поможем спроектировать архитектуру, собрать прототип и привести документ к требованиям кафедры. Первая консультация бесплатная, разбираем вашу тему и состав глав.
Источник: Торговля лекарствами и ПВЗ из-под палки: власти подготовили закон о спасении «Почты России» (опубликовано 2026-03-25)