Провести технический челлендж, в котором участники разрабатывают и нагрузочно тестируют сервис по продаже билетов. Цель — продемонстрировать устойчивость решений при высокой нагрузке (RPS — запросов в секунду).
- Организаторы публикуют условия и предоставляют инфраструктуру.
- Участники разворачивают собственные мини-сервисы на выделенных поддоменах.
- Выполняется стресс-тестирование всех решений.
- Производится сравнение по метрикам производительности (например, RPS).
- Продвижение в соцсетях и технических сообществах.
- Подготовка лендинга с описанием условий и регистрацией.
- Разработка стресс-теста (нагрузочный инструмент, метрики).
- Подготовка тестовых данных (события, тексты, изображения).
- Разработка фиктивной платёжной системы.
- Проработка децентрализованной архитектуры: каждый участник может разворачивать свою мини-инфраструктуру.
- У организаторов — основной домен.
- Участникам выдаются поддомены, которые указывают на их IP (сервер/облако).
- Предоставление общего стенда с базовыми тестами и инструментами.
- Участникам предлагается задача «сделай Ticketon».
- Следует чётко определить, какие части не входят в задание (например, сложная UI-часть, полноценная работа с платежами).
- Для эмуляции оплаты — фиктивная платёжная система с предопределёнными сценариями (успешно / неуспешно).
- Возможность тестирования решений на общем стенде с двумя серверами (API + БД/бэкенд).
- Участники разрабатывают только бекенд для сервиса бронирования и покупки билетов.
- Организаторы предоставляют:
- Описание API (например, OpenAPI/Swagger).
- Фронтенд, подключённый к API.
- Набор тестовых данных.
- Метрики:
- RPS (запросов в секунду)
- Время отклика
- Количество ошибок
- Система баллов за:
- Производительность
- Устойчивость
- Чистоту архитектуры
- Опциональные награды:
- За оригинальные решения
- За автоматизацию и CI/CD
- За лучшую документацию