Что использовать для outbox паттерн?

Question

[utsiye]

Есть монолитное приложение на FastAPI. Необходимо обеспечить event consistency при операциях создания/удаления. Например, при удалении сообщения нужно атомарно:

1. Удалить запись из БД
2. Удалить файл из S3
3. Разослать уведомление по WebSocket (in-memory хранятся)

- Монолит, микросервисов нет
- Message broker (RabbitMQ и т.п.) кажется избыточным

Думал над вариантом с Outbox-таблицей + функция в том же процессе, что и fastapi, которая поллит таблицу и обрабатывает события без брокера, а напрямую обращается к s3/websocket.

Вопрос: Насколько жизнеспособен подход Outbox-таблица + polling в данном контексте? Какие подводные камни у этого решения и есть ли более подходящие альтернативы для монолита с подобными требованиями?

Comments

[utsiye]

«Пользователь удалён», я неправильно выразился. Под атомарностью я имел ввиду "сделать пару независимых ретраев". Спасибо за идею с редисом, но как мне передавать объекты вебсокетов?

[utsiye]

«Пользователь удалён», тоесть схема работы такая:
В транзакции добавляем ивент в outbox таблицу.
Отдельный воркер проверяет таблицу, запускает нужные для ивентов функции, следит за ретраями. Если это то, что он может выполнить сам (удаление файла из s3), то делает это. А если не может этого сделать (вебсокеты), то отправляет сообщение через pub/sub в главное приложение, которое через менеджер вебсокетов передает сообщение.
Верно?

[utsiye]

«Пользователь удалён», если редис упадет, то все данные сотрутся. Даже при rdb не будет полного at least once. А если ивенты будет хранить воркер, то воркер сам может упасть и потерять часть данных. Также, какие плюсы у отдельного воркера по сравнению с такой же функцией в том же процессе, что и fastapi/основное приложение?

[utsiye]

«Пользователь удалён», спасибо, почитал, действительно полноценный брокер. О taskiq слышал много плохого. Остался последний вопрос - какие плюсы есть у отдельного воркера по сравнению с такой же функцией, но в том же процессе, что и основное приложение?

[utsiye]

«Пользователь удалён», проблемы с логером, то были логи, то нет. Проблемы с поиском задач. Да и тут он не нужен, если редис будет.

[utsiye]

«Пользователь удалён», я видел, что не прелесть. Раз таких проблем нет, то можно попробовать. Но мне бы сейчас определиться, делать ли отдельный воркер. Плюсов пока я найти не могу, по сравнению со слиянием в один процесс

Answer 1

[Дмитрий]

при удалении сообщения нужно атомарно:

1. Удалить запись из БД
2. Удалить файл из S3
3. Разослать уведомление по WebSocket (in-memory хранятся)

А зачем вообще все три составляющие пихать в транзакцию?
Тут атомарность и транзакционность только для БД нужна, для остального нужна идемпотентность и асинхронность. Удаление из S3 это просто "подчистка кеша/артефактов" по сути, а WebSocket — как ненадёжный best-effort event notify hint. Последние два могут вообще прийти заметно позже, чем факт транзакции в БД, кто от этого пострадает то? Просто держишь БД за источник консистентной истины, а остальное доводишь уже в отдельном воркере асинхронно как логический коммит.

Например, можно при транзакции БД помечать записать как soft-deleted, а уже когда отрабатывает полный коммит подчистки всех артефактов, можно сделать hard delete, если память не бесконечная.

Поллинг — ну такое, лучше будет pub/sub. Поллинг можно оставить как fallback.

Comments

[utsiye]

Полной атомарности достичь очень трудно, так что этот outbox я рассматривал как обработчик ретраев и фильтратор для неудачных вызовов (если после х ретраев всеравно неудача). Я бы сделал pub/sub, но у меня вебсокеты, которые непонятно как передавать в json. Они же живут в одном процессе. А делать пинг-понг из запросов как-то странно.