Banknext microservice: a case study

This article is about “BankNext” A case study of ： It includes digital transformation 、 Customer induction process and event driven and hidden mines .

Business objectives

“ BankNext ” Is in an ambitious phase of digital transformation , And hope to make it Seamless connection of customer induction process . After detailed functional process analysis ,BankNext Implements an orchestration Architecture , You can collaborate between various microservices .

The business process

1. start-up ： Prospects in BankNext Start the join process on
2. Pre inspection ：BankNext First call Screening MSvc and Data deduplication Msvc To study potential customers and ensure that the entity does not exist in the system
3. Handle （ After passing the pre inspection ）：CustomerMgt Msvc Create a customer entity ,AccountMgt Msvc Create... For this customer Account Entity .
4. Compliance ： In the initial stage monitor Msvc To check for suspicious activity and recommend Msvc To provide customer satisfaction based on customer preferences .

Build feedback

BankNext Very satisfied with this architecture , Here's why ：

1. Entity Orchestrator Msvc It provides the system with the ability to collaborate among multiple microservices .
2. The coordinator can sort and synchronize the calls .
3. The choreographer based on the response from the invoked microservice / Adjust the operation abnormally .
4. Coordinators benefit from asynchronous parallel calls by cleverly using the future that can be accomplished , As long as the calls are not interdependent .

Build negative feedback

BankNext Soon realized ： We have a question ：

1. Unexpected... Occurs when invoking and collating responses from multiple microservices Delay .
2. Suppose that each Msvc need 300ms, So all 7 The total time required is at least 1 second （ namely 300ms * 7）.
3. This kind of waiting makes potential customers unhappy .
4. Any new Msvc The introduction of will force Orchestrator Write the call explicitly , This can lead to undesirable Tightly coupled .

Back to planning

After in-depth analysis , The engineering and business teams jointly determined that the root cause of the delay was the longest running service .

Business Review

The business review concluded , Filtering and deduplication pre checks are mandatory . Once through , The user can clearly get an account , Therefore, a confirmation message can be sent . Monitoring and recommendation are ancillary services , The user's confirmation shall not be delayed .

Technical challenges

To achieve this business vision , System design must evolve to break the process , In order to send the user confirmation immediately after the pre check . The rest of the process , Customer creation and account creation 、 Monitoring and recommendation should asynchronous happen . This will greatly improve the user experience .

 

Technology implementation

1. The engineering team immediately realized Event driven orchestration Will be the right way to solve this challenge .
2. After successful pre check ,EntityMgt Msvc* This new entity txn Publish to Kafka “ *new_entity_initiated_topic ”.
3. EntityMgt Msvc Send initial confirmation information back to the user .
4. CustomerMgt Msvc subscribe Kafka “new_entity_initiated_topic” And use this event .
5. CustomerMgt Msvc Create a customer in the system and publish this event to Kafka “ new_customer_created_topic ”.
6. AccountMgt Msvc subscribe Kafka “ new_customer_created_topic ” And use this event .
7. AccountMgt Msvc Create an account for the customer in the system and publish this event to Kafka “ new_account_created_topic ”
8. The new entity is successfully created in the system .
9. Support services , I.e. monitoring Msvc And recommendations Msvc subscribe Kafka “ new_account_created_topic ”.

10. Because this process is asynchronous , Therefore, a new Notification Msvc Notify customers of account details .

11. This Notification Msvc You can simply subscribe Kafka “ new_account_created_topic ” Quickly connect to this new architecture .

The advantages of the new architecture

1. Significantly improved responsiveness to customers .
2. Eliminate tight coupling , Because explicit service calls are no longer required . The system only needs to know which topics to publish or subscribe to .
3. By subscribing to the right topic , Can quickly integrate new services , To gain great future flexibility .

New building negative factors ： Hidden mines

1. As flexibility increases , This architecture brings higher system complexity .
2. By introducing robust messaging components , Major infrastructure enhancements to enable event driven processing .
3. Observability 、 The ability of system debugging and tracking needs to be significantly improved , To troubleshoot the fault scenario .
4. State management 、 Retry and system wide rollback mechanisms add complexity .
5. The atomicity of the system needs to be detailed SAGA Realization

Abstract ： framework 、TechStack And basic principles

Architecture goals	strategic	Technology stack	The basic principle
Flexible and scalable integration	Topics	Topics	Eliminate centralized coordinator dependencies
Event driven capability	The messaging system	Kafka	eliminate svcs Close coupling between
Future capability efficiency	Publish/Subscribe	Kafka	Eliminate explicit new svc Call call
System wide observability	Centralized logging/tracing	ELK/Sleuth	Asynchronous logging and observability
Heavy volume/TPS	Streaming	Kafka/Async operations	Very low latency
Parallel aggregation	A future that can be accomplished	java	General purpose
frame	Microservices	Springboot	General purpose