Developing a vision of how business logic is built into the landscape is essential when designing a core banking architecture. Thus, choosing between choreography or orchestration processes can make a difference in how seamlessly services function behind the scenes. But what is relevant to know when selecting one or the other?
In essence, choreography and orchestration are two methods of connecting services to create a sequence of events within a distributed system architecture. Various systems are involved: emails, authentication via the banking app, the CRM system, the database, and, in some cases, even external systems. For example: If a client fills out a change request for something, a series of tasks to check the validity of that request follows. You can arrange for that sequence of tasks and events using either choreography or orchestration.
With choreography or chaining, the services themselves know what happens next. If you have a microservice, you instruct it to carry out an operation, and then it sends a message that it’s done. Another service knows it needs to respond to that event and initiates its operation. Like dancers that recognize the music and know the dance to it, all parts of the architecture know their choreography and respond to their surroundings accordingly.
With orchestration, a part of the solution knows that a particular service needs to be used for specific functionality. Like a conductor in front of an orchestra, the orchestration solution tells the other components within the architecture what needs to be done.
In general, your architectural landscape as a bank, lender, or crowdfunding provider is built up of many components. The requirements for compliance are high, as is the standard for security. This leads to challenges concerning the integration.
An example is the need to log everything that happens within the system. Choreography and Orchestration are two ways to ensure that processes occur as you intended. Choosing one or the other has pros and cons.
With choreography, you can easily introduce new functionality to the existing architecture. There are little to no dependencies. You just add it, deploy it, and it’s there.
The other microservices, however, do not know it is there. If they either intently or inadvertently subscribe to particular events, this can cause unintended behavior within the landscape. It is then difficult to identify what exactly happened. Things can be hardcoded and challenging to find. There is no single source of information when it comes to process administration. This needs to be actively documented in the bespoke documentation of the architectural landscape.
With orchestration, there is an action needed for every microservice introduced to the landscape to define the business logic. This makes deploying singular functionality a little harder than in the choreography scenario. When something unexpected happens, however, all logic can be found in a single location. This makes it easier to tell where things went wrong, stagnated, or led to an unwanted outcome. This offers more control.
Having everything in one central place does cause a dependency between the orchestrator and the services. If you want to add new functionality to the flow or replace existing functionality, you must add it to the central orchestration.
When designing the banking architecture, it is important to develop a vision of the way business logic is built into the landscape. Both choreography and orchestration are highly decoupled. There are benefits and downsides to both. Choreography is a bit faster at the implementation stage, but the orchestration is faster and more reliable when finding the cause of issues. Orchestration is the more robust way that offers more control.