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?

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to