Advanced Engineer Challenge

Не забудьте сперва поставить Star. Спасибо!

UPD: Вакансия немного переехала. Смотрите ссылку.

Этот репозиторий — инженерный челлендж для кандидатов на backend/fullstack позиции.

Задача специально узкая по продукту, но широкая по архитектуре: мы оцениваем не «как быстро собрать формы логина», а то, как вы проектируете систему.

Контекст

Вам нужно реализовать модуль аутентификации для 3 пользовательских сценариев:

1. Регистрация
2. Авторизация
3. Восстановление пароля

UI-дизайн (https://www.figma.com/design/31KetUbya482vMSGgyiNIf/Orbitto-%7C-Service--Copy-?node-id=102-12806&t=TMlkJ3c3j3vJF5fb-4) уже подготовлен и будет отправной точкой для клиентской части.

Что важно

Решение должно демонстрировать инженерную зрелость:

• DDD (явные bounded context, модель домена, язык предметной области)
• CQRS (разделение команд и запросов)
• IaC (воспроизводимое окружение инфраструктуры)
• Осознанный выбор языка и стека (язык выбираете на своё усмотрение, но выбор нужно аргументировать)

CRUD + controller + stock REST auth по документации не считается целевым уровнем решения для этого челленджа.

Обязательные требования

1. Архитектура

• Покажите доменную модель и границы контекстов.
• Выделите command side и query side (даже если в упрощенном виде).
• Опишите ключевые инварианты и бизнес-правила (например, правила reset-token, валидация пароля, ограничения на повторную отправку).

2. API/протокол взаимодействия

• Предпочтительный уровень: gRPC и/или GraphQL.
• Только REST допустим исключительно при сильной архитектурной аргументации, иначе это будет существенным минусом.

3. Infrastructure as Code

• Запуск окружения должен быть описан кодом.
• Минимум: локально воспроизводимый стенд (например, Docker Compose).
• Плюс в оценке: Terraform/Kubernetes manifests/Helm.

4. Безопасность

• Без хранения паролей в открытом виде.
• Корректная работа с токенами/сессиями.
• Защита базовых auth-флоу (rate limiting, expiration, replay/abuse considerations).

5. Наблюдаемость и качество

• Логи, метрики или трейсинг (минимум один из блоков).
• Тесты критичных участков (доменные правила, auth-флоу, интеграционные точки).

6. Технологические решения

• Язык программирования и фреймворки выбираете самостоятельно.
• В README обязательно зафиксируйте, почему выбрали именно этот стек и какие альтернативы рассматривали.

Ограничения и анти-паттерны

Следующие подходы считаются слабым решением:

• Полностью «коробочный» auth-провайдер без вашей архитектурной проработки домена.
• Копирование шаблонного туториала без обоснования trade-offs.
• Монолитный слой handlers/controllers без разделения доменной и инфраструктурной логики.

Можно использовать библиотеки для криптографии, JWT, транспорта и т.д., но архитектурные решения должны быть вашими.

Что нужно сдать

1. Исходный код в вашем fork.
2. Обновленный README в вашем fork с:

• как запустить проект;
• архитектурная схема (можно Mermaid/PlantUML);
• объяснение, где в решении DDD, CQRS и IaC;
• ключевые компромиссы (trade-offs);
• что сделали бы следующим шагом в production-версии.

3. Минимальный набор тестов и инструкции по их запуску.

Формат выполнения

1. Сделайте fork этого репозитория.
2. Пройдите Pinterest-челлендж:

• соберите moodboard;
• соберите anti-moodboard.

3. Реализуйте решение в своем fork.
4. Оформите результат в README.
5. Отправьте 3 ссылки в отклике:

• ссылка на moodboard;
• ссылка на anti-moodboard;
• ссылка на ваш fork.

Использование ИИ

• Использование ИИ-инструментов в рамках челленджа разрешено.
• Если используете ИИ, добавьте в ваш fork папку .agents, чтобы было видно, каким образом вы строили процесс решения.

Критерии оценки

1. Архитектурное мышление (DDD/CQRS/IaC).
2. Качество инженерных решений и аргументация trade-offs.
3. Надежность и безопасность auth-флоу.
4. Чистота кода и тестовое покрытие критичных сценариев.
5. Операбельность: насколько легко поднять и проверить решение.

Бонусные сигналы

• Event-driven взаимодействие между компонентами.
• Service mesh / policy-driven networking (если уместно и обосновано).
• Продуманная стратегия эволюции схемы данных и backward compatibility.
• ADR (Architecture Decision Records) для ключевых решений.

Важно

Нас интересует не «идеальный продакшен за вечер», а качество инженерного мышления и способность строить систему осознанно.