followup on AKKA Microservices (Reactive) Communication

[Dagny T]

THANK YOU to the person who had asked the original question on this!

I'd like to learn from a concrete example (at least from a UML interface/sequence diagram-level) which distills the fundamental design concepts for how to design one respectable Akka Microservice using a "Bounded-Context"; and which communicates with one other Microservice using a (different) "Bounded-Context".  Would be THRILLED if someone could please share a reliable Blog resource on this topic that speaks in: "I-need-to-build-this-so-talk-to-me-with-concrete-details".

POSSIBLE EXAMPLES:

From the familiar online shopping domain

- a Customer Order Service talking to a Seller Fulfillment Service

From the familiar stock purchase domain:

- a Client Stock Buy Order Service talking to a Broker Stock Fulfillment Service

QUESTIONS (i.e. do Old-School Design techniques still apply, and if not; how to evolve, exactly?):

1) What if there's a connection failure; and a message gets dropped?  How do you:  (a) Detect that case in a performant way?  (b) Recover from that in a performant way?

OLD-SCHOOL:  Buy Order gets dropped -- So Buy Service waits for an ACKnowledge from Fulfillment service; then retries after a time interval?  Then shows error message to User after X retries?

2) What if the Order Service changes its Order Format?  How do you:  (a) Have the Fulfillment Service understand this new version and not choke on the new format?

OLD-SCHOOL:  Put Version Numbers within the message format between Services; and spin up new Fulfillment instance with dedicated Case-pattern for servicing only the new message version Type to avoid extended case-pattern-matching logic or inefficient message filters?   

3) What if you have a Buy Program Sequence you need to execute -- i.e. BUY Lightbend, then BUY FunctionalDemocracy, but only if the first buy transaction completed?

OLD-SCHOOL:  Buy Service has Actor accumulating Buy Program Execution Progress; and waits for Fulfillment Service ACKnowledge before going to the next step?

And, does this Use Case necessarily eliminate the NEW SCHOOL Optimistic State Updates in the Client's UI; therefore Client UI (necessarily) experiences a somewhat non-responsive WAIT time?