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.