Есть ли опыт работы с R2DBC?

Что проверяют

Работали ли вы с реактивным стеком по-настоящему или знаете его по статьям, и понимаете ли, когда R2DBC оправдан, а когда только усложняет код. Следом почти всегда спрашивают про транзакции и про то, почему бы не взять виртуальные потоки с обычным JDBC.

Как отвечать

Стройте ответ от своего проекта: какой сервис, почему выбрали реактивный стек, какая база и нагрузка. Цифры нужны ваши: придуманный «прирост на 30%» разваливается на первом уточняющем вопросе. Каркас:

• что это: R2DBC это спецификация неблокирующего доступа к реляционным базам, а не драйвер. Драйверы есть для PostgreSQL, MySQL, SQL Server, Oracle, H2;
• как подключали: Spring Data R2DBC с R2dbcRepository, для сложных запросов DatabaseClient или R2dbcEntityTemplate. Методы возвращают Mono и Flux, пул соединений через r2dbc-pool;
• транзакции: @Transactional на реактивном методе через R2dbcTransactionManager или явный TransactionalOperator. Транзакция живёт в Reactor Context, а не в ThreadLocal;
• ограничения: это не JPA. Нет ленивой загрузки и связей вроде @OneToMany, связанные сущности собираются вручную. Flyway и Liquibase для миграций всё равно ходят через JDBC;
• зачем: выигрыш в пропускной способности при большом числе одновременных запросов на малом числе потоков, а не в скорости отдельного запроса.

Если опыта нет, скажите прямо и покажите, что понимаете модель: писали на WebFlux или Reactor, знаете, чем опасна блокировка в цепочке. Добавьте, что с Java 21 виртуальные потоки с обычным JDBC закрывают многие задачи R2DBC при заметно более простом коде.

Где спотыкаются

Вызывают блокирующий код внутри реактивной цепочки: JDBC-репозиторий, block(), синхронный HTTP-клиент. Потоки event loop встают, и сервис деградирует сильнее обычного блокирующего.

Утверждают, что R2DBC ускоряет запросы. Сам запрос в базе выполняется столько же.

Ждут, что MDC для логов и всё, что держится на ThreadLocal, будет работать как раньше. В реактивном коде контекст нужно переносить явно.