Skip to main content

Before Starting MicroServices just walk through Orchestration !! Matters a lot

What is this Orchestration :

Orchestration is the traditional way of handling interactions between different services in Service-Oriented Architecture (SOA). With orchestration process, there is typically one controller that acts as the “orchestrator” of the overall service interactions. This typically follows a request/response type pattern.

For example, if three services needed to be called in a particular order, the orchestrator makes a call to each one, waiting for a response before calling the next. 


As you can identify the differences of two flow as seen in the picture.

PROS: 

Provides a good way for controlling the flow of the application when there is synchronous processing. For example, if one Service  needs to complete successfully before another Service  is invoked.

CONS:

  • If there is a central shared instance of the orchestrator for all requests, then the orchestrator is a single point of failure. If it goes down, all processing stops.
  • Leverages synchronous processing that blocks requests.
Reactive architecture patterns solve for some of the orchestration challenges listed above.  
Reactive architecture pattern is an event-driven architecture pattern applied to microservices. Instead of having a central orchestrator that controls the logic of what steps happen when, that logic is built into each service ahead of time.
Services use an event stream for asynchronous communication of events. Multiple services can consume the same events, do some processing, and then produce their own events back into the event stream, all at the same time. The event stream does not have any logic and is intended to be a dumb pipe.
The asynchronous nature of a reactive architecture removes the blocking, or waiting, that happens with orchestration (request/response) type processing. Services can produce events and keep processing. 
Pros:
  • Enables faster end-to-end processing as services can be executed in parallel/asynchronously.
  • Easier to add/update services as they can be plugged in/out of the event stream easily.
  • Aligns well with an agile delivery model as teams can focus on particular services instead of the entire application.
  • Control is distributed, so there is no longer a single orchestrator serving as a central point of failure.
  • Several patterns can be used with a reactive architecture to provide additional benefits. For example, Event Sourcing is when the Event Stream stores all of the events and enables event replay. This way, if a service went down while events were still being produced, when it came back online it could replay those events to catch back up. 

Comments

Popular posts from this blog

LOVE THE WAY SINGLETON PATTERN CAN BE DESIGNED ! WOWW...

To implement Singleton pattern, we have different approaches : 1.Eager initialization: In this method the instance of clss is created at loading time .As whenever in java there is a requirement of species at loading time we first remember of Static keyword. package com.questprogram.singleton; public class EagerInitializedSingleton { private static final EagerInitializedSingleton instance = new EagerInitializedSingleton(); //private constructor to avoid client applications to use constructor private EagerInitializedSingleton(){} public static EagerInitializedSingleton getInstance(){ return instance; } } 2. Static block initialization Static Block initialization implementation is similar to eager initialization, except that instance of class is created in the static block that provides option for exception handling. package com.questprogram.singleton; public class StaticBlockSingleton { private static StaticBlockSingleton in

10 points to know about volatile variable in JAVA?

Volatile variable have some specific uses.It's better to know all the major reason  why java adopt such variables .Please found the below 10 points which need to be noticed: 1.Volatile variable always get allocated in the main memory.To allocate any variable in main memory volatile keyword is used. 2.Precisely volatile variable are always read and write directly from main memory.It doesn't perform any operation from CPU 's cache. 3.Volatile variable after JAVA 5 guranatees the visibilty of changes to variable across multiple threads. 4.Volatile also provide atomicity in some cases e.g .while reading double and long data types. 5.In case of volatile long and  volatile double data types which are of 64 bytes the read operation is atomic. 6. If you know that a long field is accessed by more than one thread e.g. a counter or anything, you better make it volatile. Why? because reading to a long variable is not atomic in Java and done in two steps, If one thread is w