When we developing a loosely coupled and reusable application, often arises the question: how to arrange
communication between services or applications?
To a large extent, it depends on the nature of the request and the granularity of your applications or services.
We will discuss the two classic microservice integration patterns: service choreography and orchestration.
What is the difference between these two modes of communication? Which one we should use? How to
ensure data consistency? How to implement disturbed transactions?
We will discuss these issues, also we do not forget the issues of logging, monitoring and alerting in
choreography and orchestration system.

Choreographic or
orchestral architecture
the right way of micro-services communications

1
Topics
Services… How did we get to this?
2 Micro-services: communication approaches
4 Logging, monitoring, alerting
3
Transactions: how to ensure data consistency
between services?
5 Conclusion

Services...
How did we get to this?

Benefits:
● can work very well even for large applications
● easier debugging and testing
● simple to develop/deploy
Tradeoffs:
● becomes too complicated to understand when application scales up
● harder to implement changes
● cannot scale components independently
● cannot deploy components independently
Monolithic Architecture a monolithic application is built as a single and indivisible unit. Simply means that all
of the application code is deployed and run as a single process on a single node.

usually:
● supports multiple message protocols
● maximizes application reusability
● connecting services to each other
● focused on business functionality reuse
● use of a common platform for all services
deployed to it
● common governance and standards
Service-Oriented Architecture is essentially a collection of services. These services communicate with each
other. The communication can involve either simple data passing or two or more services coordinating some
activity. Some means of connecting services to each other is needed.
Service orientation is a paradigm that frames what you do. (SOA manifesto: http://www.soa-manifesto.org)

Service-Oriented Architecture - cohesion of components

Microservices, in a way, are the next step in the evolution of Service Oriented Architectures.
A bounded context refers to the coupling of a component and its data as a single unit with minimal
dependencies.
usually:
● CI/CD as core value
● stateless
● minimize on sharing of components
● low coupling
● high cohesion (bounded context)
● native to cloud-based development
● higher scalability and flexibility
● faster turnaround

● extra complexity: support and set up the connections between all the modules and databases. All
services have to be deployed independently
● system distribution: when creating a new microservices application, we should handle a number of
cross-cutting concerns: logging, metrics, externalized configuration, health checks…
● testing: quality assurance of code, system and contracts
between services is being much harder cause multiple of
independently deployable components
● debugging: holy hell

Micro-services
communication approaches

Orchestral approach Orchestration is the traditional way of handling interactions between different
services in Micro-Service Architecture. With orchestration, there is typically one controller that acts as the
“orchestrator” of the overall service interactions.
This typically follows a request/response type pattern.
usually:
● communicate services via HTTP/gRPC...
● aggregate response from different services
● allows different request flows
● sync/async requests to couple of services
● provide public API

Benefits:
● a good way for controlling the flow of the application
● low coupling
● saving contacts in one place
Tradeoffs:
● infrastructure difficulties
● system monitoring complexity
● failure of one component results in a request error
● orchestrator is a single point of failure
Provides a good way for controlling the flow of the application when there is synchronous processing.
For example, if Service A needs to complete successfully before Service B is invoked.

The World’s Most Popular Open Source Microservice API Gateway&Platform.
● decentralization
● independent deployment
● fault Isolation
● services to develop independently of each other
● invoke serverless functions via APIs
● transform requests and responses on the fly
● kubernetes integration

● authentication and Security
● dynamic Routing
● load balancing
● static response handling
● multiregion resiliency
● insights and monitoring
Zuul is an edge service that provides dynamic routing, monitoring, resiliency, security...
How Netflix use Zuul

NodeJS Orchestration Sample
The previously proposed solutions do not provide such flexibility in transaction
management - which we would like to have.
If we need flexibility in managing our transactions, it is recommended to use
in-house solution.

usually:
● services are connected to a message broker
● services just subscribe channels they are interested in
● once an event series occurs that matters of the service, the service performs the appropriate action.
● now it is easy to add new services to the architecture;
● in the worst case must to ensure that the other services emit the events that the new service requires.
● adding additional events or extending the payload of existing events won’t break existing logic
Choreography approach - applying a choreography pattern means that one service doesn’t talk to another
service in order to instruct an action. Instead each service is observing its environment and acts on events
autonomous.
Note: When it comes to create/read/update/delete entities the REST protocol should still be a consideration. The service that
handles the REST call could then trigger an event that a new entity was created/updated/deleted.

Event driven architecture patterns solve for some of the orchestration challenges listed above.

Benefits:
● faster end-to-end processing
● can be executed asynchronously
● easier to add/update services
● great aligns with an agile delivery model
● teams now focus on particular services
● control is distributed
● no longer a single orchestrator serving as a central point of failure
● several patterns can be use: event sourcing, CQRS…
Tradeoffs:
● async mindset
● significant for developers
● complexity is shifted
● count of services are increased

Kafka is generally used for two broad classes of applications:
● Building real-time streaming data pipelines that reliably get data
between systems or applications
● Building real-time streaming applications that transform or react to the
streams of data
A streaming platform has three key capabilities:
● Publish and subscribe to streams of records, similar to a
message queue or enterprise messaging system.
● Store streams of records in a fault-tolerant durable way.
● Process streams of records as they occur.

Patterns of Enterprise Application Architecture
by Martin Fowler

● Our application can’t use ACID transactions - entities are now spread into multiple databases.
● In case of failure in one of micro-service, state recovery can’t be attained by “two phase
commit” while rollback of transaction
● one to many relationships becomes even more challenging
Challenge!
To ensure the data consistency we need to implement distributed transaction

03
Transactions
How to ensure data consistency between services?

● saga is a sequence of local transactions where each transaction updates data within a single
service
● each service which changes the state of the database in a distributed transaction can generate
an event which can trigger the next micro service
● in case of a failure, the saga triggers a sequence of compensating roll back events from one
service to the other in the reverse direction.
To handle this scenario, saga pattern can be used!

These sagas can be designed using two techniques:
● choreography, in which each service can trigger other service’s event without a central
coordinator
● orchestration, in which a central coordinator makes the decision of triggering the relevant
events in the saga
SAGA

Create order flow

● no central coordination
● each service produces and listen to other service’s events
● depends on event decides if an action should be taken
● micro-service executes a local transaction
● proceeds till the last service which doesn’t publish any more events, there by marking the end of
transaction
Choreography approach

Choreography approach - create order flow

Rollback a distributed transaction doesn’t come for free. We have to implement
another operation/transaction to compensate for what has been done before.

● central coordination
● one service listen to other service’s events
● depends on http/grpc response decides if an action should be taken
● micro-service executes a local transaction
● proceeds till the last service send response
Orchestration approach

Orchestration approach: create order flow

Orchestration approach - rollback

04
Logging, monitoring, alerting

Istio — connect, manage, and secure microservices
● Istio uses the Envoy proxy to transparently add in the service
mesh functionality
● Istio provides uniform observability, mTLS-based security, and
traffic management.
● Istio can be used with both Kubernetes-based workloads as
well as workloads deployed on VMs.

Istio features
● Request routing by versions or routing
environment
● Leverages service registry (service
discovery)
● Load balancing (envoy)
● Service-to-service communication:
HTTP1.1 or HTTP/2, gRPC or TCP
● Canary releases

Istio features

● Elastic - powerful and highly scalable search engine
● Kibana lets us visualize your Elasticsearch data and navigate the Elastic Stack
● Logstash ingests data from a multitude of sources simultaneously, transforms it,
and then sends it to elastic.
Elastic Logstash Kibana

Prometheus (TSDB)
● open-source systems monitoring and alerting toolkit originally
built at SoundCloud
● full monitoring and trending system that includes built-in and
active scraping, storing, querying, graphing, and alerting
based on time series data
● multidimensional data model with time series data identified
by metric name and key/value pairs
● time series collection happens via a pull model over HTTP
● multiple modes of graphing and dashboarding support

Alerting rules allow you to define alert conditions based on
Prometheus expression language expressions and to send
notifications about firing alerts to an external service
● Grouping categorizes alerts of similar nature into a single
notification
● Defining alerting rules
● Templating
- {{ $value }}
- {{ $labels.<labelname> }}
● Sending alert notifications by custom channels
Prometheus - alerting

Zipkin is a distributed tracing system
Zipkin

Conclusion

Orchestration, Choreography - can apply in different scenarios and use cases
So, what is better: orchestration or choreography?
None is necessarily better than the others or applicable for all needs.
Keep in mind that you can also combine these two approaches.
Conclusion