Microservices — Event driven & the hidden landmines
Business Objective -
“BankNext” is on a ambitious digital transformation phase and desires to makes it’s customer onboarding process seamless.
After an elaborate functional flow analysis, BankNext implemented an orchestration architecture to collaborate between various microsevices -
Business Flow -
1- Initiation
Prospective customer initiates the joining process on BankNext
2 -Prechecks
BankNext first invokes a Screening MSvc and a Deduplication Msvc to study the prospect and ensure that this entity is not already present in the system
3 -Processing (after prechecks pass)-
CustomerMgt Msvc to create the Customer entity
AccountMgt Msvc to create the Account entity for this customer
4 -Compliance
Monitoring Msvc for the initial period to check suspicious activities
Recommendation Msvc to provide customer delight based on customer’s preferences
Architecture Positives -
BankNext is quiet happy with this architecture because -
1- Entity Orchestrator Msvc provides the system the ability to collaborate between multiple microservices
2- Orchestrator is able to sequence and synchronize the invocations
3- Orchestrator adjusts the actions responsively according to responses/exceptions from the called microservices
4- Orchestrator cleverly uses the completable futures to benefit from Async parallel calls wherever the calls are not interdependent
Architecture Negatives-
BankNext quickly realizes: (Houston) we have a problem(s) -
1- Undesirable latency when invoking and collating responses from multiple microservices
2- Assume each Msvc requires 300ms, the total time required for all 7 would be a minimum of 2.1seconds (i.e. 300ms * 7)
3- This wait makes the prospective customer unhappy
4- Introduction of any new Msvc compels the Orchestrator to explicitly write that invocation call which causes an undesirable tight coupling
Back to the Drawing Board-
After thorough analysis, the engineering and business teams together determine that the root cause of the latency are the longer running services.
Business Review-
Business review concludes that Screening and Deduplication prechecks are mandatory. Once passed the user is in the clear to get an account, hence a confirmation can be sent out. The monitoring and recommendation are secondary services and should not delay the user confirmation.
Technical Challenge -
In order to implement this business vision, the system design had to evolve in to breaking the flow such that the user confirmation is sent immediately after prechecks. The remaining processes i.e customer creation and account creation, monitoring and recommendation should happen asynchronously. This would greatly enhance the user experience.
Technical Implementation -
1- Engineering team immediately realizes that an Event-Driven Choreography would be the right approach to solve this challenge
2- After successful prechecks, EntityMgt Msvc publishes this new entity txn to the Kafka “new_entity_initiated_topic”
3- The EntityMgt Msvc sends back an initial confirmation to the user
4- CustomerMgt Msvc subscribes to the Kafka “new_entity_initiated_topic” and consumes this event
5- CustomerMgt Msvc creates the customer in the system and publishes this event to the Kafka “new_customer_created_topic”.
6- AccountMgt Msvc subscribes to the Kafka “new_customer_created_topic” and consumes this event.
7- AccountMgt Msvc creates the account for this customer in the system and publishes this event to the Kafka “new_account_created_topic”
8- The new entity is successfully created in the system
9- Supporting Services i.e Monitoring Msvc and Recommendation Msvc subscribe to the Kafka “new_account_created_topic”
10- Since this process is asynchronous, a new Notification Msvc is also required to notify account details to the customer
11- This Notification Msvc can be quickly hooked up in to this new architecture by simply subscribing it to the Kafka “new_account_created_topic”
New Architecture Positives -
1- Significant improvement in responsiveness to the customer
2- Elimination of tight coupling because explicit service call is no longer needed. The system only needs to know the topic to publish or subscribe
3- Tremendous future flexibility as new services can quickly be incorporated by subscribing to the correct topic
New Architecture Negatives (hidden landmines)-
1- With the improved flexibility this architecture brings higher system complexity
2- Major infrastructure enhancement to enable the event driven processing with introduction of robust messaging components
3- Observability, system debugging and tracing capabilities need to be significantly improved to troubleshoot failure scenarios
4- State management, retries and system wide rollback mechanisms add to the complexity
5- Requires elaborate SAGA implementation (will be covered in the next article) for system atomicity
Summary : Architecture, TechStack & Rationale
Github : https://github.com/vijayredkar/event-driven-platform
