Depois de pesquisar um pouco mais, me deparei com artigo do qual tirei algumas citações que acho úteis para o que quero realizar (e para qualquer futuro leitor). Isso oferece uma maneira de adotar um modelo de programação reativa sobre um modelo de programação imperativo.
Fornecimento de eventos
The idea here is to represent every application’s state transition in
a form of an immutable event. Events are then stored in a log or
journal form as they occur (also referred to as ‘event store’). They
can also be queried and stored indefinitely, aiming to represent how
the application’s state, as a whole, evolved over time.
O que isso ajuda a conseguir é que, se um microsserviço cair, outros eventos pertinentes a ele estão sendo publicados, os eventos
e são consumidos por, digamos, outras instâncias desse microsserviço, quando esse microsserviço voltar , pode se referir a esse
event store
para recuperar todos os eventos que ele perdeu durante o período em que caiu.
Apache Kafka como agente de eventos
Considere o uso do Apache Kafka, que pode armazenar e despachar milhares de eventos por segundo e possui mecanismos integrados de replicação e tolerância a falhas. Ele tem um armazenamento persistente de eventos que podem ser armazenados em disco indefinidamente e consumidos a qualquer momento (mas não removidos) do Tópico (a fila de fantasia do Kafka) foram entregues.
The events are then assigned offsets that univocally identify them
within the Topic — Kafka can manage the offsets itself, easily
providing “at most once” or “at least once” delivery semantics, but
they can also be negotiated when an event consumer joins a Topic,
allowing microservices to start consuming events from any arbitrary
place in time — usually from where the consumer left off. If the last
consumed event offset is transactionally persisted in the services’s
local storage when the usecases ‘successfully complete’, that offset
can easily be used to achieve an “exactly once” event delivery
semantics.
Na verdade, quando os consumidores se identificam com Kafka, Kafka registra quais mensagens foram entregues a qual consumidor, para que ele não seja exibido novamente.
Sagas
For more complex usecases where the communication among different
services is indeed necessary, the responsibility of finishing the
usecase must be well recognized — the usecase is decentralized and
only finishes when all the services involved acknowledge their task as
successfully completed, otherwise the whole usecase must fail and
corrective measures must be triggered to rollback any invalid local
state.
É quando a saga entra em cena. Uma saga é uma sequência de transações locais. Cada transação local atualiza o banco de dados e publica uma mensagem ou evento para acionar a próxima transação local na saga. Se uma transação local falhar porque viola uma regra de negócios, a saga executa uma série de transações de compensação que desfazem as alterações feitas pelas transações locais anteriores. Leia este para obter mais informações.