diff --git a/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md b/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md
index f845d6c..3229f0c 100644
--- a/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md	
+++ b/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md	
@@ -1,38 +1,470 @@
-## 📝 Задача: Система управления событиями
+### 📝 10 прикладных задач для Middle Java-разработчика
+
+## 🎯 Задача 1: Система управления складскими операциями
 
 ### **Условие:**
 
-Вы разрабатываете систему для управления событиями (конференции, вебинары, встречи). Нужно реализовать сервис регистрации участников с учетом следующих требований:
+Вы разрабатываете модуль WMS для управления операциями приемки товаров на склад. Система должна обрабатывать поступление товаров от поставщиков.
 
-1. **Событие** имеет:
+1. **Поставка** имеет:
     
-    - ID, название, описание
-    - Дату начала и окончания
-    - Максимальное количество участников
-    - Статус (DRAFT, PUBLISHED, CANCELLED)
-2. **Участник** имеет:
+    - ID, номер поставки, поставщик
+    - Плановую и фактическую дату прибытия
+    - Статус (PLANNED, ARRIVED, IN_PROGRESS, COMPLETED, CANCELLED)
+2. **Товарная позиция** содержит:
     
-    - ID, имя, email
-    - Дату регистрации
+    - SKU товара, плановое количество
+    - Фактически принятое количество
+    - Статус приемки (PENDING, ACCEPTED, REJECTED, PARTIAL)
 3. **Бизнес-правила:**
     
-    - Регистрация возможна только на опубликованные события
-    - Нельзя зарегистрироваться на событие, которое уже началось
-    - Нельзя превысить лимит участников
-    - Один участник может зарегистрироваться на событие только один раз
-    - При отмене события нужно уведомить всех участников
+    - Приемка возможна только для прибывших поставок
+    - Нельзя принять больше товара, чем заявлено в поставке
+    - При расхождениях создается акт о расхождениях
+    - После завершения приемки обновляется остаток на складе
+    - При отмене поставки нужно освободить зарезервированные ячейки
 
 ### **Техническое задание:**
 
-**Опишите подход к решению задачи:**
+Опишите подход к решению:
 
-1. **Архитектуру приложения** - какие слои нужны
-2. **Entity классы** - основные поля и связи
-3. **Ключевые методы EventRegistrationService**
-4. **Обработку бизнес-правил** - где и как валидировать
-5. **REST API endpoints** - какие нужны
-6. **Обработку ошибок** - типы исключений
-7. **Транзакции** - где нужны и почему
-8. **Тестирование** - что важно покрыть тестами
+1. **Архитектуру приложения** - слои и компоненты
+2. **Entity классы** - модель данных
+3. **Ключевые методы ReceivingService**
+4. **Валидацию бизнес-правил**
+5. **REST API endpoints**
+6. **Обработку исключений**
+7. **Управление транзакциями**
+8. **Стратегию тестирования**
 
-**Время на выполнение:** 25 минут
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 2: Система уведомлений с приоритизацией
+
+### **Условие:**
+
+Разрабатывается сервис уведомлений для корпоративного приложения. Система должна отправлять уведомления различными каналами с учетом приоритетов.
+
+1. **Уведомление** содержит:
+    
+    - ID, получатель, тема, содержание
+    - Приоритет (LOW, NORMAL, HIGH, CRITICAL)
+    - Каналы доставки (EMAIL, SMS, PUSH)
+    - Статус (PENDING, SENT, FAILED, DELIVERED)
+2. **Шаблон уведомления** имеет:
+    
+    - Тип события, шаблон сообщения
+    - Настройки каналов по умолчанию
+    - Параметры для подстановки
+3. **Бизнес-правила:**
+    
+    - CRITICAL уведомления отправляются немедленно всеми каналами
+    - HIGH - в течение 5 минут, предпочтительные каналы
+    - NORMAL - батчами каждые 15 минут
+    - LOW - раз в час группами
+    - При неудаче повторная отправка через экспоненциальный backoff
+    - Дедупликация одинаковых уведомлений
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Архитектуру решения** - асинхронная обработка
+2. **Модель данных** - entities и relationships
+3. **NotificationService методы**
+4. **Стратегию приоритизации**
+5. **API для создания уведомлений**
+6. **Error handling и retry логику**
+7. **Использование очередей**
+8. **Тестирование асинхронных процессов**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 3: Система управления задачами роботов
+
+### **Условие:**
+
+Создается система для управления автоматизированными роботами на складе. Роботы выполняют задачи перемещения товаров между локациями.
+
+1. **Робот** имеет:
+    
+    - ID, тип, текущая локация
+    - Статус (IDLE, BUSY, MAINTENANCE, ERROR)
+    - Грузоподъемность, заряд батареи
+    - Текущая задача
+2. **Задача** содержит:
+    
+    - ID, тип операции (MOVE, PICK, PLACE)
+    - Локация источник и назначение
+    - Приоритет, крайний срок выполнения
+    - Статус (QUEUED, ASSIGNED, IN_PROGRESS, COMPLETED, FAILED)
+3. **Бизнес-правила:**
+    
+    - Задачи назначаются ближайшему свободному роботу
+    - Учитывается грузоподъемность и тип робота
+    - При низком заряде робот отправляется на зарядку
+    - Высокоприоритетные задачи могут прерывать обычные
+    - При сбое задача переназначается другому роботу
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Системную архитектуру**
+2. **Доменную модель**
+3. **RobotTaskService логику**
+4. **Алгоритм назначения задач**
+5. **API для управления роботами**
+6. **Обработку сбоев**
+7. **Coordination между роботами**
+8. **Тестирование concurrent операций**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 4: Система управления скидками и промокодами
+
+### **Условие:**
+
+Разрабатывается модуль для e-commerce платформы, управляющий скидками и промокодами с различными условиями применения.
+
+1. **Скидка** имеет:
+    
+    - ID, название, описание
+    - Тип (PERCENTAGE, FIXED_AMOUNT, FREE_SHIPPING)
+    - Значение скидки
+    - Период действия, лимит использований
+2. **Промокод** содержит:
+    
+    - Код, связанная скидка
+    - Условия применения (минимальная сумма, категории товаров)
+    - Количество использований на пользователя
+    - Статус (ACTIVE, EXPIRED, EXHAUSTED)
+3. **Бизнес-правила:**
+    
+    - Промокод можно применить только к подходящим товарам
+    - Один заказ может содержать несколько скидок
+    - Скидки применяются в порядке приоритета
+    - Нельзя превысить максимальный процент скидки (например, 80%)
+    - Скидки на доставку несовместимы друг с другом
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Архитектуру модуля**
+2. **Entity модель**
+3. **DiscountService функциональность**
+4. **Логику валидации и применения**
+5. **REST endpoints**
+6. **Обработку конфликтов скидок**
+7. **Транзакционность операций**
+8. **Unit и integration тесты**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 5: Система резервирования ресурсов
+
+### **Условие:**
+
+Создается система для резервирования переговорных комнат, оборудования и других ресурсов в офисе компании.
+
+1. **Ресурс** имеет:
+    
+    - ID, название, тип (ROOM, EQUIPMENT, VEHICLE)
+    - Вместимость, локация
+    - Доступное время работы
+    - Статус (AVAILABLE, OCCUPIED, MAINTENANCE)
+2. **Резервирование** содержит:
+    
+    - ID, пользователь, ресурс
+    - Время начала и окончания
+    - Цель использования
+    - Статус (PENDING, CONFIRMED, CANCELLED, COMPLETED)
+3. **Бизнес-правила:**
+    
+    - Нельзя забронировать занятый ресурс
+    - Резервирование возможно только на будущее время
+    - Автоматическая отмена неподтвержденных бронирований через 15 минут
+    - Recurring резервирования (еженедельные встречи)
+    - Приоритет для VIP пользователей
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Системную архитектуру**
+2. **Модель данных**
+3. **ReservationService методы**
+4. **Conflict resolution логику**
+5. **API endpoints**
+6. **Exception handling**
+7. **Scheduled tasks для cleanup**
+8. **Тестирование concurrent бронирований**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 6: Система мониторинга производительности API
+
+### **Условие:**
+
+Разрабатывается система для мониторинга производительности и доступности API endpoints различных микросервисов.
+
+1. **API Endpoint** имеет:
+    
+    - URL, HTTP метод, сервис
+    - SLA параметры (latency, availability)
+    - Частота проверок
+    - Критичность (LOW, MEDIUM, HIGH, CRITICAL)
+2. **Метрика** содержит:
+    
+    - Timestamp, endpoint, response time
+    - HTTP статус код, размер ответа
+    - Статус проверки (SUCCESS, TIMEOUT, ERROR)
+3. **Бизнес-правила:**
+    
+    - Критичные endpoints проверяются каждые 30 секунд
+    - Обычные - каждые 5 минут
+    - При превышении SLA генерируется alert
+    - Escalation при множественных сбоях
+    - Автоматическое отключение проблемных endpoints из балансировщика
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Архитектуру monitoring системы**
+2. **Data model**
+3. **MonitoringService функции**
+4. **Alerting механизм**
+5. **Reporting API**
+6. **Circuit breaker интеграцию**
+7. **Async обработку проверок**
+8. **Performance тестирование**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 7: Система управления документооборотом
+
+### **Условие:**
+
+Создается система для управления корпоративными документами с workflow для согласования и утверждения.
+
+1. **Документ** имеет:
+    
+    - ID, название, тип, версия
+    - Автор, дата создания
+    - Содержимое, вложения
+    - Статус (DRAFT, REVIEW, APPROVED, REJECTED, ARCHIVED)
+2. **Workflow** содержит:
+    
+    - Этапы согласования
+    - Участники (роли или конкретные пользователи)
+    - Условия перехода между этапами
+    - Временные ограничения
+3. **Бизнес-правила:**
+    
+    - Документ проходит все этапы workflow по порядку
+    - На каждом этапе могут быть множественные approvers
+    - При отклонении документ возвращается автору
+    - Возможны параллельные и условные этапы
+    - Автоматическая эскалация при превышении сроков
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Архитектурный подход**
+2. **Domain model**
+3. **WorkflowService логику**
+4. **State management**
+5. **Document API**
+6. **Notification интеграцию**
+7. **Versioning стратегию**
+8. **Тестирование workflow сценариев**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 8: Система управления инвентаризацией
+
+### **Условие:**
+
+Разрабатывается модуль для проведения инвентаризации товаров на складе с поддержкой различных методов подсчета.
+
+1. **Инвентаризация** имеет:
+    
+    - ID, дата проведения, ответственный
+    - Тип (FULL, PARTIAL, CYCLE_COUNT)
+    - Зоны склада для проверки
+    - Статус (PLANNED, IN_PROGRESS, COMPLETED, CANCELLED)
+2. **Позиция инвентаризации** содержит:
+    
+    - SKU товара, локация
+    - Ожидаемое количество (по системе)
+    - Фактическое количество (по подсчету)
+    - Расхождение, причина расхождения
+3. **Бизнес-правила:**
+    
+    - Во время инвентаризации блокируются операции в проверяемых зонах
+    - Расхождения свыше порога требуют пересчета
+    - Автоматическая корректировка остатков после утверждения
+    - Генерация отчетов о расхождениях
+    - Cycle counting по ABC анализу
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Системную архитектуру**
+2. **Модель данных**
+3. **InventoryService методы**
+4. **Locking механизм**
+5. **API для mobile приложений**
+6. **Exception scenarios**
+7. **Concurrency control**
+8. **Accuracy testing**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 9: Система управления конфигурациями
+
+### **Условие:**
+
+Создается централизованная система управления конфигурациями для множества микросервисов с поддержкой версионирования и hot reload.
+
+1. **Конфигурация** имеет:
+    
+    - Ключ, значение, тип данных
+    - Сервис, окружение (dev/test/prod)
+    - Версия, дата изменения
+    - Статус (DRAFT, ACTIVE, DEPRECATED)
+2. **Изменение конфигурации** содержит:
+    
+    - Старое и новое значение
+    - Автор изменения, комментарий
+    - Время применения
+    - Статус применения
+3. **Бизнес-правила:**
+    
+    - Изменения в prod требуют дополнительного утверждения
+    - Возможность отката к предыдущей версии
+    - Валидация значений по схеме
+    - Encrypted значения для sensitive данных
+    - Audit trail всех изменений
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Architecture design**
+2. **Data model**
+3. **ConfigurationService API**
+4. **Validation framework**
+5. **REST API design**
+6. **Security considerations**
+7. **Version control strategy**
+8. **Integration testing approach**
+
+**Время:** 25 минут
+
+---
+
+## 🎯 Задача 10: Система аналитики пользовательского поведения
+
+### **Условие:**
+
+Разрабатывается система для сбора и анализа событий пользовательского поведения в веб-приложении с real-time обработкой.
+
+1. **Событие** имеет:
+    
+    - ID, тип события, пользователь
+    - Timestamp, session ID
+    - Метаданные (страница, действие, параметры)
+    - Источник (web, mobile, api)
+2. **Сессия** содержит:
+    
+    - ID сессии, пользователь
+    - Время начала и окончания
+    - Количество событий, страниц
+    - Conversion events
+3. **Бизнес-правила:**
+    
+    - События обрабатываются в real-time
+    - Агрегация метрик по различным измерениям
+    - Обнаружение аномалий в поведении
+    - GDPR compliance - возможность удаления данных пользователя
+    - Retention анализ и funnel metrics
+
+### **Техническое задание:**
+
+Опишите:
+
+1. **Event-driven архитектуру**
+2. **Data schema design**
+3. **AnalyticsService компоненты**
+4. **Real-time processing pipeline**
+5. **Query API для дашбордов**
+6. **Privacy compliance**
+7. **Stream processing с Kafka**
+8. **Load testing стратегию**
+
+**Время:** 25 минут
+
+---
+
+## 📋 Рекомендации по оценке решений
+
+### **Критерии оценки (для каждой задачи):**
+
+**Архитектура (25%):**
+
+- Правильное разделение на слои
+- Понимание принципов SOLID
+- Separation of concerns
+
+**Модель данных (20%):**
+
+- Корректное проектирование entities
+- Понимание relationships
+- Учет performance implications
+
+**Бизнес-логика (25%):**
+
+- Правильная обработка бизнес-правил
+- Валидация и error handling
+- Edge cases consideration
+
+**API Design (15%):**
+
+- RESTful principles
+- Proper HTTP methods и status codes
+- Request/Response design
+
+**Качество кода (15%):**
+
+- Тестирование стратегия
+- Transaction management
+- Exception handling
+
+### **Уровни оценки:**
+
+- **Senior level:** Полное решение со всеми деталями, best practices, edge cases
+- **Middle level:** Основные компоненты покрыты, базовая архитектура правильная
+- **Junior level:** Базовое понимание задачи, простое решение
+
+Каждая задача покрывает ключевые навыки Middle разработчика и может быть адаптирована под специфику вашей складской логистики добавлением warehouse-specific деталей.
\ No newline at end of file