Как радикальный вариант — избавиться от всех промежуточных звеньев (шина и т.п.)
Сделать read (slave) реплику основной базы, а 1С дать "интерфейс" в виде хранимок/вьюшек над этой репликой и пусть сама вычитывает с нужной периодичностью.

Другой вариант — перейти на push модель, вместо publish/subscribe.
Т.е. пусть не 1С слушает изменения в основной системе, а основная система пушит в 1С при возникновении изменений (исправлении ошибок и т.п.)

Как радикальный вариант — избавиться от всех промежуточных звеньев (шина и т.п.)
Сделать read (slave) реплику основной базы, а 1С дать "интерфейс" в виде хранимок/вьюшек над этой репликой и пусть сама вычитывает с нужной периодичностью.

Другой вариант — перейти на push модель, вместо publish/subscribe.
Т.е. пусть не 1С слушает изменения в основной системе, а основная система пушит в 1С при возникновении изменений (исправлении ошибок и т.п.)

И еще мысль.
Если считать, что данные в основной базе всегда согласованы,
то не очень понятно, в какой момент возникает возможность для рассогласовывания в 1С:
в момент зачитки данных для выгрузки в шину, при трансформации в DTO, при обработке/записи на стороне 1С?
В чем источник проблемы: временной лаг на propagation изменений по шине, необходимость параллельной обработки потока изменений на 1С или у нас просто неудачная DTO-модель?