О проекте
Мы строим новое ядро TicketNet — мультиарендной платформы продажи билетов — и ищем Java-разработчика, который будет писать его сервисы.
Платформа работает сейчас, но на легаси: логика продаж живёт в сервисах виджета и в процедурах Oracle, бронь места держится блокировкой на всю транзакцию заказа, события теряются при доставке, арендатор определяется по HTTP-заголовкам. Целевая архитектура описана до уровня компонентов (C4 Level 3) и согласована: десять сервисов на Java и Spring Boot, свои модели в PostgreSQL, события с гарантией доставки через Kafka, Oracle остаётся только адаптером миграционного слоя.
Это работа не на поддержке и не на доработках: дизайн готов, сервисы предстоит написать с нуля. Часть решений ещё открыта и обсуждается — язык правил, разбиение инвентаря больших залов, хранение ключей подписи на edge-узлах.
Чем предстоит заниматься
Разрабатывать сервисы ядра продаж и платформы расширений по утверждённому дизайну.
•Инвентарь мест и квоты — единственный владелец статуса места. Защита от двойной продажи строится на атомарном условном обновлении вместо долгих блокировок. Самый нагруженный участок системы.
•Заказы и билеты — оркестрация процесса от создания до возврата: таймауты, компенсации, идемпотентные повторы, подписанный QR-код билета.
•Корзина, каталог мероприятий, схемы залов — состояние в Redis, read-модели, версионирование схем.
•Платформа расширений — настройки арендатора с наследованием, движок правил, хаб вебхуков, каталог коннекторов.
Отдельный пласт работы — общие библиотеки, одна версия на все десять сервисов: контекст арендатора из JWT с RLS в PostgreSQL, outbox с доставкой «хотя бы один раз», идемпотентность, встроенный вычислитель правил, клиент синхронных хуков с бюджетом времени, трассировка.
И миграция: перенести логику из легаси-сервисов виджета и свести связь с Oracle к одному адаптеру, который потом отключается.
Что мы ждём
От четырёх лет коммерческой разработки на Java и опыт самостоятельного ведения сервиса от проектирования до прода.
•Java и Spring Boot. Версия не критична, но проект на Java 25 и Spring Boot 4.1 — готовность работать на свежих версиях обязательна.
•PostgreSQL на уровне понимания, а не ORM. Уровни изоляции, блокировки, гонки, умение читать план запроса.
•Опыт с Kafka или другой шиной. Гарантии доставки, дедупликация у потребителя, порядок событий, повторная обработка.
•Порты и адаптеры. Способность держать домен свободным от знания о БД, HTTP и очередях — это базовое требование к коду, а не пожелание.
•Тесты как часть работы. JUnit, Testcontainers, тесты на реальных PostgreSQL и Kafka вместо моков инфраструктуры.
•Умение писать и читать ADR. Решения у нас фиксируются текстом с аргументацией, а не устно.
Будет плюсом
Ничто из этого не обязательно, но каждый пункт снимает месяц разгона.
•Борьба с гонками в бронировании или продажах ограниченного ресурса — билеты, места, складские остатки.
•Multi-tenancy и row-level security в PostgreSQL.
•Миграции с Oracle на PostgreSQL, умение читать чужой PL/SQL.
•Плагинные платформы: вебхуки, синхронные точки расширения, изоляция чужого кода.
•Языки правил — CEL, Drools или собственные вычислители.
•Keycloak, Vault или OpenBao, MinIO, Redis.
•Нагрузочное тестирование и OpenTelemetry.
Стек
| Область | Технологии |
|---|---|
| Язык и фреймворк | Java 25, Spring Boot 4.1 |
| Хранилища | PostgreSQL с RLS, Redis, MinIO |
| Асинхронность | Kafka, outbox-релей |
| Безопасность | Keycloak (JWT), OpenBao |
| Правила | CEL, собственная rules-lib |
| Наблюдаемость | OpenTelemetry, Prometheus |
| Тесты | JUnit, Testcontainers |
| CI и контракты | GitLab CI, OpenAPI, AsyncAPI |
| Легаси на время миграции | Oracle |
Как мы работаем
Каждая задача идёт по цепочке ТЗ → план → ADR: решение сначала описывается и обсуждается, потом кодится. Архитектура задокументирована до уровня компонентов, так что угадывать замысел не придётся.
Дизайн считается подтверждённым только после трёх видов проверок: контрактные тесты по OpenAPI и AsyncAPI, интеграционные на Testcontainers без моков инфраструктуры и нагрузочный тест конкурентной брони — 110 запросов в секунду на один объект при нулевом числе двойных продаж.
Отбор
•Скрининг, 30 минут — опыт и ожидания.
•Техническое интервью, полтора часа — конкурентность, транзакции, проектирование сервиса. Без алгоритмов на скорость.
•Разбор реального фрагмента архитектуры TicketNet с тимлидом, час — вопросы и возражения приветствуются.
•Оффер.
Мы предлагаем
•Работа в стабильной, полностью «белой» компании.
•Оформление с первого рабочего дня согласно ТК РФ.
•Аккредитованная IT-компания, которая заботится о сотрудниках.
•Гибкий график: обсуждаем старт (9.00ч. – 11.00ч. утра до 18.00ч. – 20.00ч. вечера).
•ДМС, после прохождения испытательного срока.
•Комфортный офис рядом с метро, безлимитный кофе.
•Профессиональная команда, в которой ценят инициативу и опыт.
