То что долгих транзакций в вебе не бывает (или непринято, или еще что) - это довольно распространенное заблуждение, распространяемое бракоделами, если исходить из UX, то ничто не мешает нам когда мы хотим обновить пару миллиардов записей пользователю в браузер кидать сообщение, что обновился очередной миллион и он у себя будет наблюдать некий прогресс-бар и видеть что система не зависла, а помимо этого существуют еще фоновые задания, которые вообще ничего про пользователей не знают и там транзакции можно сутками держать, собственно, если исходить из того что разница между вставкой и фиксацией может занимать пару секунд, то ничего не мешает этой разнице занимать и пару часов - разница или есть или ее нет, поэтому ваша компенсация этой разницы в виде: это ни что иное как полная хрень, потому что есть более ровный алгоритм, описанный ранее и работающий в Oracle уже десятки лет.

вот я пишу:

в каком месте у меня появляется гарантия в 0.01 сек?

Вот давайте на примере...

допустим мы имеем такую структуру:
- есть книжка, у книжки автор: book(id, title, author_id, modify_date)
- у автора имя: person(id, name)

Есть внешняя система, с которой мы синхронизируем изменения, система хранит данные в виде book(id, title, author_name) и мы какбы об этом знаем. Что должно происходить когда у person меняется name а нам нужно это как-то отправить во внешнюю систему? Варианты видятся следующие:
- пишем лог что у автора изменилось имя, дальше подключается ETL/ELT и начинается написание довольно стремного кода по выяснению где этот person еще участвует. Завтра разработчики системы добавили еще пару таблиц ссылающихся на person и наш ETL/ELT развалился
- в хибере ловим изменения в person и делаем условный update book set modify_date=sysdate - бизнес-логика за рамки приложения не вышла (аргумент типа "мы можем что-то потерять" - никакой не аргумент, я в предыдущем пункте обосновал), однако получаем дополнительную блокировку на обновляемых строках - идея так себе, потому что мы в СУБД изначально имеем возможность организовывать данные таким образом, чтобы где-то избегать конкуренции, а где-то, наоборот, порождать, тут же получается подход как у некоторых имбецилов, которые хранят данные в виде table(id, json) и у них возникает конкуренция на любой чих
- в хибере ловим изменения в person и вместо update делаем insert into book_log(id, change) - бизнес-логика там где и должна быть, блокировок лишних нет.


Вопрос изначально был не про репликацию, а про бизнес-события.

Какой именно механизм гарантиует, что транзакция будет длиться на 0.01 сек, а не две секунды и не час?

Ну не знаю... вроде алгоритм простой: в лог пишем не текущую дату, а заведомо бОльшую, заведомо бОльшая дата - это как NULL, но по ней еще индекс можно строить, в итоге запрос в духе "дай там, то что еще не видели" будет выглядеть как "select * from .. where dt > last_seen", без каких-то компенсаций, повторных обработок и пр. Кроме этого, его еще можно раскатывать на несколько консамеров, путем сериализации доступа к логу и выставления "dt" в значение даты запуска.

Могу поспорить, что в этом OeBS (тут вроде даже не знают как слово suite читается ) какой-нить org chart представлен не меньше чем десятком таблиц, а может и двумя десятками, так вот в ИС, у которой org chart - это не основная функциональность, нужно из этого десятка таблиц только штуки 3-4, причем уже в другой структуре, а не так как это давным-давно увидели индусы из оракла, к тому же вопрос с репликацией уже был раскрыт здесь
Это уже в духе предыдущего оратора про RPC через очереди сообщений: "пофиг что оно медленно, у кого-то же работает". То что бывают ситуации когда иначе никак (другими словами: архитекторы ИС не предусмотрели отправку событий/запись журнала по основным бизнес-сущностям, а те кто систему сопровождает/интегрируется за десяток лет так и не удосужились написать фиче-реквест), совершенно не означает что в реальности всегда нужно так делать, в особенности когда есть более другие способы.