The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Jon Freedman (9) [Avatar] Offline
One of the two requirements is stated as "We must only process a royalty exactly once" but what happens if there is a network issue in step 11 of fig 8.10. Given you remove from RocksDB in step 10 won't you re-process the royalty twice?

Without using 2PC I believe you want to re-order these, possibly with a further optional "cleanup" step.

That would give you:
9: Log Event: record upstream receipt
10: ACK Event: notify streaming API
11: Remove Event: we know payment system has processed and we have notified streaming API
12: Remove: delete from RocksDB
13: (Omitted) Check for any outstanding RocksDB entries and reconcile with payment processor
14: (Optional) Check for any outstanding RocksDB entries and reconcile with streaming API

The the problem point would be at step 10 if the streaming API does not notify you it's received your ACK (won't process that message again but stays in RocksDB for ever without cleanup)

I guess you may want to elaborate on the call-out for step 8 too, I guess there by using the write-and-read approach descried in 8.1.3

Chris Richardson proposes a library (which is not yet public) in his Microservices Patterns MEAP called TARR which does not have the Remove Event. I believe you must either keep a record of everything processed or make the modifications above?
andrew.psaltis (33) [Avatar] Offline
Thank you for your feedback and pointing this out. I am in the process of adopting your changes.