А вот если и на фронте должно быть всё асинхронно,

то тогда запрос на бек должен только зарегистрировать команду CreateBook и уже либо отдельный метод наружу будет торчать, для пуллинга статуса выполнения команды, либо придет событие через WebSocket о изменении статуса команды.
только тут вопрос целесообразности. почему нельзя дождаться синхронно выполнения CreateBook? это слишком сложная и длительная операция, что стандартного http таймаута недостаточно?

а неужели нет более удачного способа получить синхронный ответ из кафки? все таки перепиливать все ресты на такой вот пуллинг звучит как-то очень странно

если все взаимодействие между сервисами через кафку сделано, то как можно синхронно дождаться то?

слушать топик на предмет появления события с нужным corellationId - тут можно и заблокироваться, а можно и асинхронно ответ отдать

вот может что-то вроде такого https://docs.spring.io/spring-kafka/reference/html/#replying-template

что значит получить синхронный ответ? собственно тот вариант, который описал Сергей - рабочий. мы можем держать http-коннекшен и дожидаться события и уже отдать ответ. но его реализация совсем не тривиальна и будет "дорога" в поддержке и сопровождении

но как я понимаю рекомендуют pull со стороны вебклиента делать https://www.confluent.io/resources/kafka-summit-2020/synchronous-commands-over-apache-kafka/

ReplyingKafkaTemplate не рассматривали? https://dzone.com/articles/synchronous-kafka-using-spring-request-reply-1

Да, рассматривали. Но пока не используем спринг.

мессадж аутбокс паттерн база + очередь