Каковы ваши профессиональные ожидания от этой беседы?

Ну, слушай, вот ты пишешь про «содержательный технический диалог», а у меня сразу в голове картинка: сидит такой интервьюер, весь из себя важный, с бородой клиновидной, и думает: «Щас я его на аннотациях @Transactional поймаю, сука!». А я ему такой: «Давай, блядь, давай! Только давай не про то, где ставить — на класс или метод, это любой дурак в туториале прочитает. Давай про propagation, isolation и про то, как эта хуйня под капотом с EntityManager’ом и connection’ами из пула танцует. И почему, если накосячить, можно получить, блядь, миллион коннектов или транзакцию, которая висит, как сопля на морозе».

Архитектурные паттерны, говоришь? О, ёпта, это моя любимая песня. Тут главное — не бросаться словами «микросервисы» и «гексагональная архитектура», как угорелый. Потому что, блядь, если у тебя три пользователя в месяц и CRUD на пять таблиц, то тебе не микросервисы нужны, а мозги в голову. Я могу рассказать, как из монолита, который похож на слоёный пирог из спагетти-кода, выковыривали бизнес-логину, оборачивали её в сервисы, и как потом эти сервисы начинали, сука, друг другу в Hibernate-кеше мозги выносить. Trade-offs? Да их, блядь, овердохуища! Каждая красивая картинка из презентации в реальности оборачивается пиздецом с distributed транзакциями, eventual consistency и отладкой, когда один сервис орёт, что не видит данные от другого, а они просто в другом контексте персистентности живут.

// Вот смотри, классика жанра, которая всех на собеседовании бесит:
@Service
public class SomeServiceImpl {
    @Transactional
    public void doSomething(Entity entity) {
        // ... какая-то логика
        entity.setStatus("PROCESSING");
        // save не вызываем, оно само из контекста выплывет
        someInternalMethod(entity);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void someInternalMethod(Entity entity) {
        // Новый контекст, новая транзакция, блядь!
        // И entity тут уже detached, если не merge сделать.
        // Вот на этом месте половина кандидатов начинает нервно курить.
    }
}

Производительность? О, это святое. Можно, конечно, тупо включить show_sql и увидеть N+1 проблему. Но это уровень юнца. А вот когда у тебя, сука, второй уровень кэша Hibernate (L2 Cache) в кластере начинает косячить из-за некорректной инвалидации, и данные в редисе не совпадают с тем, что в базе — вот тут начинается настоящий детектив. Или когда @OneToMany с FetchType.LAZY в цикле начинает дергать по запросу на каждую сущность — это, блядь, даже не проблема, это позор. Но и слепо всё EAGER делать — тоже путь в ад. Надо думать, ёпта! Смотреть план запроса, смотреть, что там JOIN FETCH делает, или лучше отдельным запросом с пагинацией всё вытащить.

И legacy-код… Э, сабака сука! Это отдельная история. Когда видишь класс на 5000 строк, где половина методов — static, и всё завязано на синглтоны, которые сами себе данные в static Map’ах держат… Волнение ебать! Терпения ноль ебать! Но подходить надо с умом: не ломануться всё сразу переписывать, а, как сапёр, потихоньку обкладывать тестами, вычленять куски, изолировать их, а потом уже, как хирург-пиздец, отрезать гниющую часть и ставить протез из нормального кода.

Так что давай свои вопросы. Самые сложные. Про ClassLoader’ы в Spring Boot, про то, как @Async может доиграться с транзакциями, или как спроектировать систему, где нужно согласованно обновить данные в двух разных БД. Я готов. Мой ProblemSolver уже потирает ручки.

public class InterviewReadiness {
    // ... всё как у тебя
    public Solution answer(Question question) {
        if (question.isAboutBuzzwords()) {
            return new Solution("Отвечу, но потом расскажу, почему это часто хуйня в вашем контексте.");
        }
        return solver.resolve(question, knowledge); // Здесь, блядь, реальная работа
    }
}

Короче, я не просто синтаксис помню. Я понимаю, откуда ноги у проблем растут и как их, этих проблем, жопу на место поставить. Погнали.