Профессия:
Декомпозиция экрана оформления заказа в приложении доставки еды
1. Описание процесса работы экрана
Экран оформления заказа — это финальный шаг в воронке покупки, где пользователь подтверждает выбранные блюда, применяет скидки, выбирает условия доставки и способ оплаты.
Основной процесс:
Нефункциональные требования для высоконагруженной системы бронирования билетов
КОНТЕКСТ
1. ПРОИЗВОДИТЕЛЬНОСТЬ (Performance)
NFR-101: Время отклика (Response Time)
Требования по типам операций:
| Операция | P50 (медиана) | P95 | P99 (99-й процентиль) | Максимум |
|---|---|---|---|---|
| Поиск мероприятий | 200 ms | 500 ms | 1 sec | 2 sec |
| Просмотр доступных билетов | 300 ms | 800 ms | 1.5 sec | 3 sec |
| Бронирование билета | 500 ms | 1.5 sec | 3 sec | 5 sec |
| Оплата билета | 1000 ms | 2 sec | 4 sec | 8 sec |
| Подтверждение заказа | 200 ms | 500 ms | 1 sec | 2 sec |
Интеграция четырёх систем для выдачи банковской карты
Обзор архитектуры
Процесс выдачи карты включает 4 последовательных этапа с различными требованиями к интеграции:
1. Типы интеграции и обоснование
Форма заявки → Скоринг: Синхронная интеграция (REST API)
Обоснование:
Реализация:
Форма заявки --[HTTP POST]-> Скоринг
<-[JSON ответ]--
Таймаут: 10 секунд
Скоринг → Печать карты: Асинхронная интеграция (Message Queue)
Анализ изменения интеграции
1. Что изменится
API расширяется двумя обязательными полями place_of_work и income. Контракт меняется v1→v2. ESB требует обновления маршрутов.
2. Затронутые системы
Веб-сервис Клиенты, Скоринг, ESB, БД, Отчётность, Мониторинг.
3. Обратная совместимость
Вариант 1: API versioning (v1, v2 отдельно) Вариант 2: новые поля опциональны в старой версии Реализация: ESB проверяет версию, подставляет default-значения
4. План миграции
Недели 1-2: подготовка, документация Недели 2-4: разработка, обновление БД Недели 4-5: staging тесты Недели 5-6: production с бэкапом Недели 6-8: мониторинг
5. Тесты
Unit: валидация, маппинг, алгоритм Интеграционные: v1 e2e, v2 e2e Функциональные: новый клиент, миграция Регрессионные: v1 работает Performance: 1000 req/sec Data migration: целостность, rollback
REST API для интернет-магазина книг
Общие принципы проектирования
Базовый URL: https://api.bookstore.com/v1
Аутентификация: JWT токен в заголовке Authorization: Bearer {token}
Формат ответов: JSON
1. Эндпоинты работы с книгами
GET /books
Параметры:
- page (int): номер страницы (по умолчанию 1)
- limit (int): количество книг на странице (по умолчанию 20)
- sort (string): сортировка (price_asc, price_desc, title, rating)
- author (string): фильтр по автору
- search (string): полнотекстовый поиск
Ответ 200 OK:
{
"data": [{"id": "uuid", "title": "Война и мир", "author": "Лев Толстой", "isbn": "978-5-17-070490-8", "price": 599.99, "stock": 45, "rating": 4.8}],
"pagination": {"page": 1, "limit": 20, "total": 156}
}
GET /books/{id}
Ответ 200 OK:
{
"id": "uuid",
"title": "Война и мир",
"author": "Лев Толстой",
"isbn": "978-5-17-070490-8",
"price": 599.99,
"stock": 45
}
Решение: Проектирование процесса авторизации через SMS-код
Sequence Diagram
User (Мобильное приложение) -> Backend: 1. POST /auth/send-sms {phone: "+79991234567"}
Backend -> SMS-шлюз: 2. Отправить SMS с кодом
SMS-шлюз -> SMS-шлюз: 3. Генерирует код (6 цифр), сохраняет в очередь
SMS-шлюз -> SMS Provider: 4. Отправляет SMS на оператора
SMS Provider -> User: 5. SMS доставлена на телефон
User -> Backend: 6. POST /auth/verify-sms {phone, code}
Backend -> Backend: 7. Проверяет код (валиден ли, не истёк ли, лимит попыток)
Backend -> Database: 8. Создаёт сессию пользователя / JWT токен
Backend -> User: 9. Возвращает токен доступа (access_token, refresh_token)
User -> Backend: 10. Дальнейшие запросы с Authorization: Bearer {token}
Системы-участники
SQL-запрос для отчёта по продажам
Основное решение
SELECT
c.id,
c.name AS category_name,
ROUND(SUM(oi.quantity * oi.price)::numeric, 2) AS total_sales
FROM categories c
INNER JOIN products p ON c.id = p.category_id
INNER JOIN order_items oi ON p.id = oi.product_id
INNER JOIN orders o ON oi.order_id = o.id
WHERE o.status = 'completed'
AND o.created_at >= NOW() - INTERVAL '1 month'
GROUP BY c.id, c.name
ORDER BY total_sales DESC
LIMIT 5;
Анализ запроса
Структура соединений: Запрос связывает категории с продуктами, продукты с элементами заказов, элементы с самими заказами. Это позволяет получить полную информацию о каждой покупке.
Фильтрация данных:
Анализ противоречий в требованиях для системы управления складом
Найденные противоречия
Противоречие 1: Реальное время vs периодическая синхронизация
Маркетинг требует real-time, но IT и Логистика дают данные с задержкой от 1 часа до 24 часов. Клиент может видеть устаревшие остатки.
Противоречие 2: Резервирование vs актуальность данных
Если остатки обновляются раз в час, а резервирование идёт в реальном времени — возможна ситуация, когда товар зарезервирован, но по факту его уже нет на складе.
SQL-запросы с оконными функциями
1. Зарплата и средняя зарплата по отделу
SELECT
e.name,
d.name AS department,
e.salary,
ROUND(AVG(e.salary) OVER (PARTITION BY e.department_id), 2) AS avg_salary_by_dept
FROM employees e
INNER JOIN departments d ON e.department_id = d.id
ORDER BY e.department_id, e.salary DESC;
Объяснение:
PARTITION BY e.department_id — разделяет данные по отделамAVG(e.salary) OVER (...) — считает среднюю зарплату для каждого отделаROUND(..., 2) — округляет до 2 знаков2. Топ-3 сотрудников по зарплате в каждом отделе
User Story: Регистрация пользователя в мобильном приложении банка
Основная история
Как новый пользователь, я хочу зарегистрироваться в приложении банка через номер телефона, чтобы получить доступ к основным услугам мобильного банка и управлению своим счётом.
Критерии приёмки (Acceptance Criteria)
Сценарий 1: Успешная регистрация
Дано: Пользователь находится на экране регистрации
Когда: Пользователь вводит корректный номер телефона (+7 9XX XXX XX XX) и нажимает кнопку «Продолжить»
Тогда:
Выбор архитектуры для сервиса онлайн-обучения
1. Выбор: МОНОЛИТ на старте
Для этого проекта выбираю монолит, потом эволюция к микросервисам.
2. Обоснование
MVP за 3 месяца - монолит разрабатывается в 2x быстрее Команда 5 человек - микросервисы требуют 12+ людей Нагрузка 1000 users - монолит легко выдержит Операционная простота - 1 приложение vs 5-7 сервисов Риск MVP - может не прижиться, не инвестировать в сложность
3. Факторы решения
Общий score: Монолит 85% vs Микросервисы 15%
4. Когда переходить на микросервисы
Критерии:
Таймлайн: Месяц 12-18
State Machine Diagram для сущности "Заказ"
1. Текстовое описание диаграммы состояний
┌─────────────────────────────────────────────────────────────────────┐
│ ЖИЗНЕННЫЙ ЦИКЛ ЗАКАЗА │
└─────────────────────────────────────────────────────────────────────┘
ТЗ: Модуль уведомлений для корпоративного портала
1. Цели в бизнес-показателях
Основная цель: Повысить вовлечённость пользователей и своевременность реагирования на задачи.
KPI:
2. Ролевая модель
Администратор портала:
Решение
1. Методология
Применяю структурированный подход - разделение интересов (interests) и позиций (positions)
2. Вопросы к отделу продаж
3. Вопросы к безопасности
4. Компромиссные решения
Вариант A: RBAC (Role-Based Access Control)
Вариант B: Data Masking
Решение: BPMN-модель процесса оформления заказа
Описание архитектуры процесса
Бизнес-процесс оформления заказа в интернет-магазине представляет собой сложный процесс взаимодействия между несколькими участниками. Процесс начинается с инициирующего события (покупатель переходит на сайт) и завершается либо успешной доставкой товара, либо отклонением заказа.
Участники процесса (Swimlanes)
Процесс разделён на 5 участников:
Основной поток процесса
Начальное событие: Покупатель открывает корзину (Start Event)
Добавление товаров: Покупатель добавляет товары в корзину (Задача в lane Покупателя)
Оформление заказа: Покупатель заполняет данные доставки и подтверждает заказ (Задача)
Use Case: Возврат товара в интернет-магазине
1. Название
Return Product (UC-05: Возврат товара)
2. Акторы
Первичные акторы:
Вторичные акторы:
3. Предусловия
4. Постусловия
Решение: ER-диаграмма системы управления задачами
Обзор архитектуры модели данных
Система управления задачами требует многоуровневой иерархии сущностей с поддержкой совместной работы. Ключевая особенность — назначение нескольких исполнителей на задачу и категоризация через метки (tags), что требует использования отношений N:M.
Описание сущностей и их атрибуты
PK: user_id (UUID)
Атрибуты:
- user_id: UUID (первичный ключ)
- username: VARCHAR(255) UNIQUE NOT NULL
- email: VARCHAR(255) UNIQUE NOT NULL
- password_hash: VARCHAR(255) NOT NULL
- full_name: VARCHAR(255)
- avatar_url: TEXT
- is_active: BOOLEAN DEFAULT true
- created_at: TIMESTAMP WITH TIMEZONE
- updated_at: TIMESTAMP WITH TIMEZONE