Вообще смысл этого паттерна не в том, чтобы избежать дублей (все таки это at-least-once паттерн), а в том, чтобы не потерять событие и не получить рассинхрон при сбое. В данном случае разница между "наивным решением" и описанном в статье в атомарности записи и контролируемом ретрае.
Например, если сервис упал после записи в БД и до публикации - событие будет потеряно навсегда. Если упал после публикации и до коммита в БД, то можем получить фантомное событие, т.е. из брокера оно пришло, а в БД его нет.
По поводу outbox таблицы без брокера - это тоже валидный вариант, в данной статье приведен лишь один из вариантов реализации, в котором используется асинхронная обработка. Такой вариант нужен, когда событие может быть обработано не сразу. Подход с брокером может помочь, когда нам событие нужно обрабатывать сразу в нескольких сервисов, которые будут читать этот топик.
Вообще смысл этого паттерна не в том, чтобы избежать дублей (все таки это at-least-once паттерн), а в том, чтобы не потерять событие и не получить рассинхрон при сбое. В данном случае разница между "наивным решением" и описанном в статье в атомарности записи и контролируемом ретрае.
Например, если сервис упал после записи в БД и до публикации - событие будет потеряно навсегда. Если упал после публикации и до коммита в БД, то можем получить фантомное событие, т.е. из брокера оно пришло, а в БД его нет.
По поводу
outboxтаблицы без брокера - это тоже валидный вариант, в данной статье приведен лишь один из вариантов реализации, в котором используется асинхронная обработка. Такой вариант нужен, когда событие может быть обработано не сразу. Подход с брокером может помочь, когда нам событие нужно обрабатывать сразу в нескольких сервисов, которые будут читать этот топик.