Как организовать работу микросервисов в kafka?

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

Тут вам либо придется как то настроить кафку так, что бы из неё читал эти сообщения тот сервис который изначально делал резерв либо читать всеми инстансами и дальше уже разбирать. Насколько мне известно о kafka, то там можно сделать так, что бы сообщение получили все подписчики. Дальше можно извлечь из него id резерва и понять (сравнив с тем что в памяти), нужно его дальше обрабатывать этому инстансу или бросить. Если планируется прям очень большая нагрузка и прям куча инстансов, то наверное можно и другие схемы придумать. Например, если количество инстансов известно на этапе деплоя и не меняется в процессе работы, то можно для каждого завести свой топик в кафке. Но в кафка я не спец, поэтому с этим вопросом можно написать в тег "kafka". Он тут точно есть где то.

Как организовать работу микросервисов в kafka?

как и где опять получить список тех товаров которым хотим подтвердить резервирование ( шаг 6 )

Не совсем понимаю вопрос. У сервиса 1 этот список уже есть. Он ему пришел в п.1 и может полежать в памяти пока (вообще в переменной т к у сервиса 1 это неразрывный поток.

надеюсь правильно

В целом да, но на шаге 2 в сервисе 2 нужно создать сущность "резерв" куда и записать все зарезервированные товары. А вернуть её айдишник. Соответственно, на шаге 6 вместо списка товаров передать Id этой сущности. И сервис 2 может на этом шаге её удалить (или если была отмена резерва, вернуть товары из резерва обратно на склад и затем удалить резервирование) Где и как хранить эту сущность - детали реализации. Самое простое в той же БД где и остатки по товарам. Но если не в той же то опять же надо какой-то механизм что бы создание резерва и уменьшение количества товара производились как атомарная операция вместе.

В каком виде лучше хранить Entity заказ - количество закзаанного?

Например, если айтем с id 1 был заказан 5 раз, то я достаю его из БД и 5 раз добавляю один и тот же item в List. А потом уже сохраняю order.
Правильно ли я делаю?

Скорее всего нет. Во всяком случае доставать из БД 5 раз одну и ту же информацию совсем не хорошо. Дело в том, что обычно обращения к БД - это самое медленное, что только есть в приложении.
Но я не совсем понимаю, какой мап вам приходит ? Что там в качестве ключа ? Если там в качестве ключа id итема, который уникален для него, то никак не получится такого, что он там пять раз. Будет проще если приведете кусок кода здесь.

Как верно сгруппировать данные в запросе?

Rsa97, Нашёл аналогичный вопрос на Stackoverflow: https://stackoverflow.com/questions/49404/sql-quer...
В принятом ответе ризонно предлагают добавить колонку `isCurrent`. И я с этим соглашусь. В этом случае запросы драмматически упрощаются.

Как верно сгруппировать данные в запросе?

Rsa97, О таком варианте я конечно подумал и даже уже почти дописал... Но тут получается, что если будут две одинаковых даты, то тоже может получится не то что нужно.
И ещё я бы к внешнему запросу добавил условие `good` IN('23068', '21805', '23204', '22493', '21813', '21802', '23845') для сокращения количества строк JOIN

Как верно сгруппировать данные в запросе?

Rsa97, Да, Вы правы. Так не сработает. И что то я затрудняюсь написать запрос, который бы сработал корректно без уникального первичного ключа.