Postman is available as a standalone app as well as a chrome plugin, so you can continue to use it into next year, see http://blog.getpostman.com/2017/11/01/goodbye-postman-chrome-app/
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?
This should be updated to reflect the fact that Scala 2.12 exists:

each release comes in two versions; one for Scala 2.10 and another for Scala 2.11.

each release comes in three versions; one for each of Scala 2.10, Scala 2.11 and Scala 2.12.

I would also encourage the author to upgrade to 2.12 if possible due to the improved interoperability with Java 8 & the fact that the Kafka team recommend it: https://kafka.apache.org/downloads
Page 59 has a typo:

it will not be the last time we talk about message deliver semantics.

Should be message delivery semantics.
Page 44 of the v12 PDF, In my mind thisstarts to conjure up an old cartoon picture is missing a space between this and starts

Same on page 51, If you do implement these two techniques, youwould be able to guarantee “exactly once”
messaging. You may not have noticedduring this discussion is missing a space between you and would and noticed and during

And page 52, you may see other ways to apply message auditingthrough the
entire streaming architecture missing a space between auditing and through

And page 59, so do not worry if thisis the least bit overwhelming missing a space between this and is
In the spirit of DRY there are a few paragraphs which seem unnecessary (only 1/4 into the book so far).

Section 1.3
With an understanding of real-time and streaming systems in general under our belt, we can
now turn out attention to the architectural blueprint we will use throughout this book.
Throughout our journey we are going to follow an architectural blueprint
that allows us to talk
about all streaming systems in a generic way, our pattern language.

Section 3.2
To put this in perspective, let’s see what it looks like if we overlay these terms and pieces onto
our streaming architecture shown below in figure 3.5. Below in figure 3.5 you will see that the components of the
message queuing we have been talking about overlaid onto our streaming architecture.
One more

3.4.2 Eliminating synchronous interaction
Another way to eliminate synchronous communication while during request processing
Returning a response to its client.
Does this framework exist? I've failed to find it on Google.
v1 has a TODO on browser plugin for testing HTTP APIs - I think the best one is postman (https://www.getpostman.com/)