Orchestrated vs Choreographed Service-Oriented Architecture in large scale? -

i'm architect in large scale financial company , in beginning of implementing new business oriented infosystem across our different countries.

from on core idea has been follow microservice oriented principles as possible (and making sure engineers have read building microservices book sam newman).

by i've come crossroads. our services json rest services using swagger automated documentation, in order use these services in our business processes , making sure not write business logic services outside domain of services, we've been using camunda orchestration tool. , camunda fine (though have considered corezoid alternative), clumsy in otherwise elegant set of services.

now service orchestration concept pretty familiar engineers. 1 not entirely happy due still having central engine drives everything. incredibly expensive replace later down road (though still cheaper replace monolith). , if central engine split multiple engines (which case today), not make better.

in recent years there has been movement microservices towards choreographed (close event-driven) architecture. @ point looking advice engineers , architects have faced similar crossroad decision points.

i absolutely love idea of decoupled architecture , despite feeling killing monoliths , having elegant independent services, still detect lot of dependencies in business process whole in current orchestrated solution in should not exist.

and it's not avoiding events. have implemented events on our architecture in order decouple many processes core principle if don't need synchronized response , need notify of happening initiate process event put may caught process starts executing. , orchestration easier explain , visualize, easier tweak , modify more technical minded business users. , think easier test , validate business perspective. orchestrated architecture (usually) expects service discovery , quality automated documentation , non-functional requirements things value greatly.

all of things question me in choreographed approach since don't have first-hand experience in running in large scale - local test prototypes.

but think see coming from. i'm trying consider alternatives without having regret driving company other way in end.

perhaps can share own experience similar situation or share interesting link or two? or looking silver bullet doesn't exist yet?

services need interact - services don't interact not part of same system. search needs access catalog, cart doesn't price info page, account needs purchase history, recommender needs purchase history, cart needs verify available coupons, inventory needs know purchased etc.

service boundaries set minimize needed interactions. can make sense cut service smaller components if share database (internal structure) different aspects of service.

when services interact creates level of coupling - @ least, coupling api (json or otherwise) service has "maintain" other services can interact it.

another coupling type temporal coupling - in request-reply situations (and can eliminate in event driven systems) however, orchestration vs. choreography not these differences (even though orchestration associated request/reply) - central control , governance vs.flexibility , serendipity.

orchestration has risks migrating business logic out of services orchestration while choreography runs risk of chaos. way, direct request/reply integration has worst of both worlds wins on simplicity when systems small enough.

choosing between 2 balancing act (like architectural decisions) instance, netflix built on choreography lot of time found need control , introduced orchestration engine. nothing silver bullet :)

personally, choreography better because of reduced coupling , flexibility , favor tools open zipkin bring order chaos.

you can see partial example orchestration based arch in slides 10-22 of presentation did microservices