Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.
Давай уточню сначала по CDC: из БД 2009 в БД 2012 скорость репликации будет очень высокой, если RecID будет выделяться самой БД. Но если Rec будет выделять AOS, то он станет бутылочным горлышком, а если еще и номерные серии надо заполнять...
То же самое и с брокерами. В принципе, за счет распараллеливания и оптимизации размера пакетов - то хоть 1К в секунду,
хоть миллион. Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.
Абстрагируясь от DAX, то если мы говорим про надежную доставку, то это - запись на диск. Таким образом надо смотреть на пропускную способность сети и скорость записи на диск. Например, для
AWS это 40 000 IOPS составляет при пакете в 16 КБ и 20 000 IOPS при 32 КБ
Таким образом, я не вижу проблемы в передаче 100500 сообщений. Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля. Если доверить эту задачу БД, а служебные поля заполнять автоматом по некому шаблону механизмами БД, то данная проблема снимается. Но вряд ли этим снимается проблема последовательной обработки сообщений.
С Уважением,
Георгий