Ключевым в данной задаче является маштабирование приложения на несколько серверов (параллельная обработка пакетов документов) поскольку оно 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 и прочей чепухи которая пока что несет смысл косметический
а не перформансный.