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

Отбор

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

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

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