Ключевым в данной задаче является маштабирование приложения на несколько серверов (параллельная обработка пакетов документов) поскольку оно high load .

Так нельзя ставить задачу. Если ты хочешь изучать Spring - изучай.

Если тебе нужно сделать масштабирование - то это другие усилия в другом перпендикулярном направлении.
Их можно делать со Spring или без Spring но важно поставить приоритеты.

С точки зрения Java EE реализация понятна, а вот документации Spring не нашел никаких архитектурных концепций
Мне просто интересно а что ты вообеще хотел найти?
Шаблон параллельной обработки документов?

Вот я-бы рассмотрел эту задачу в вакууме (pure-java)

Есть операции\документы которые идут из шины Rabbit в Xml, сообщения сначала сохраняются в буфер далее Parsing и перекладываются в реляционную базу данных . Ключевым в данной задаче является маштабирование приложения на несколько серверов (параллельная обработка пакетов документов) поскольку оно high load .


и подумал что здесь собственно параллелится? Чтение из Rabbit MQ (вряд-ли)?
Parsing - эээ... скорее всегда да. Это будет идеальный параллелизм по Амдалу если
у нас на входе 1 документ и на выходе 1 независимый документ. Или россыпь data-rows
которые независимы.

Запись в БД? Да. Может быть распараллелится но я-бы сделал ставку просто на грамоттный
батчинг с регулировкой размера пачки.

Тоесть я-бы предложил проговорить эти вопросы. Сделать макет на pure-java или можете с любым фреймворков.

А потом уже сделать Spring как связующий цемент для компонентов. Просто я не хочу чтобы интересные
и сложные вопросы мультипоточки и декомпозиции XML документов на атомы с загрузкой в БД были просто
"заболтаны" под слоем всяких SpringData/Orm и прочей чепухи которая пока что несет смысл косметический
а не перформансный.

2 all.

Я-бы всё таки различал high-load и горизонтальное мастабирование. Мне кажется что одно из другого не вытекает.

Приведу примеры. Spark/Hadoop - горизонтально мастабируется но работает в импульсном режиме. Отработал запрос
и дальше - делать нечего. Это не highload. Хайлоад вообще предполагает постоянную загрузку железа на 100%
возможностей. Пока делать нечего - ноды можно выкинуть или задейстовать под что-то другое. Следующий каскад
запросов в spark придет в следующем месяце когда бизнес аналитики вернутся к месячным данным.

Еще пример. Docker/Kuber кластер обеспечивает работу бизнеса в будние дни и в праздничные дни и дни маркетинг-акций
с разницей нагрузки в 1000%. Но скорость добавление новых вычислительных ресурсов в кластер - не бесконечна.
Возможно кластер должен исполнить какие-то протоколы кворумов и согласнований. Тоесть со старта "чёрной пятницы"
кластер будет испытывать какие-то переходные процессы до того как он добавит новые ноды в кластер и согласует их.
Также нужно время чтобы клиентские сессии перебалансировались на новые адреса. Тоесть хайлоад то у нас заявлен.
Но нужно время на подготовку.

Странное опредление. А если наращивать интенсивно невозможно? Хайлоад закончился?