Java-разработчик (TicketNet)

О проекте

Мы строим новое ядро 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 запросов в секунду на один объект при нулевом числе двойных продаж.

Отбор

1. Скрининг, 30 минут — опыт и ожидания.
2. Техническое интервью, полтора часа — конкурентность, транзакции, проектирование сервиса. Без алгоритмов на скорость.
3. Разбор реального фрагмента архитектуры TicketNet с тимлидом, час — вопросы и возражения приветствуются.
4. Оффер.

Мы предлагаем:

• Работа в стабильной, полностью «белой» компании.
• Оформление с первого рабочего дня согласно ТК РФ.
• Аккредитованная IT-компания, которая заботится о сотрудниках.
• Гибкий график: обсуждаем старт (9.00ч. – 11.00ч. утра до 18.00ч. – 20.00ч. вечера)
• ДМС, после прохождения испытательного срока.
• Комфортный офис рядом с метро, безлимитный кофе;
• Профессиональная команда, в которой ценят инициативу и опыт.