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ч. вечера) ДМС, после прохождения испытательного срока. Комфортный офис рядом с метро, безлимитный кофе; Профессиональная команда, в которой ценят инициативу и опыт.