Комментарии 5
Штука интересная, но чувствую, что в ногу выстрелить очень легко. Евенты могут зациклить друг друга. Как в больших проектах этого избегают?
Чтобы избежать повторной обработки одного и того же сообщения, каждому событию назначается уникальный идентификатор. На стороне обработчика выполняется проверка по этому идентификатору — обычно через быстрое (горячее) хранилище, например Redis — было ли сообщение уже обработано.
Важно учитывать, что риск зацикливания может возникнуть при использовании политик доставки At Most Once и At Least Once. В таких случаях ответственность за обеспечение идемпотентности и защиту от повторной генерации событий ложится на саму бизнес-логику приложения.
Извините, но эти хорошо структурированные списочки вызывают смутные сомненья... — у меня одного?
Exactly once невозможна. Почитайте про задачу "Двух генералов" https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/
Здравствуйте, спасибо за статью. Просматривал листинги и пытался сам себе ответить на вопрос, "а зачем тут фастапи то"?
Идея в целом понятна, но в таком случае может лучше взять faust-streaming?
Event-Driven архитектура на FastAPI: через паттерн Pub/Sub