The document discusses BankNext's transition from a traditional microservices orchestration architecture to an event-driven choreography architecture. The traditional architecture introduced undesirable latency when invoking multiple services sequentially. The new event-driven architecture addresses this by having services publish events to Kafka topics when business events occur, allowing other services to asynchronously consume events and take action. While this improves flexibility and performance, it significantly increases architectural complexity and requires robust messaging, observability, and transaction management to maintain system reliability.

1. Microservices
Event driven & the hidden landmines

2. Business Objective
• BankNext’s ambitious digital transformation mission
• Desires to make the customer onboarding process seamless
• Elaborate functional flow analysis conducted
• Orchestration architecture implemented to collaborate between microservices

3. Traditional Orchestration Architecture

4. Business Flow
1. Initiation
Prospective customer initiates the joining process on BankNext
2. Prechecks
Screening MSvc - examine the prospect
Deduplication MSvc - ensure entity non duplicity
3. Core Services (after prechecks pass)
CustomerMgt Msvc - create Customer entity
AccountMgt Msvc - add Account to this customer
4. Compliance/Future capabilities
Monitoring Msvc - initial period suspicious activities check
Recommendation Msvc - customer delight based on customer’s preferences

5. Architecture Positives
• BankNext is quiet happy with this architecture because –
1. Entity Orchestrator Msvc enables collaboration between multiple microservices
2. Orchestrator is capable of sequencing and synchronizing the invocations
3. Orchestrator can adjust responsively react to actions/exceptions from the called microservices
4. Orchestrator cleverly uses the CompletableFutures for Async parallel calls wherever applicable

6. Architecture Negatives
• BankNext quickly realizes: (Houston) we have a problem(s)
1. Undesirable latency when invoking & collating responses from multiple msvcs
2. Rough calculation :
• Assume each Msvc call = 300ms,
• Total time for all 7 responses = 2.1seconds (i.e. 300ms * 7) minimum
• excluding n/w , other I/O latencies
3. Prospective customer very unhappy
4. Future capability addition (new msvc) compels explicit invocation call in the Orchestrator
5. Tight coupling

7. Back to the Drawing Board
• Business & Engineering teams thoroughly analyze the flow
• Conclude that the root cause of the latency are the longer running services.
• The Screening and Deduplication prechecks are mandatory.
• Once passed the prospect is cleared to get an account and can be notified immediately
• The Monitoring & Recommendation msvcs are secondary services & should not delay the user
confirmation.

8. Technical Challenge
• To meet this business vision, the system design has to evolve
• Break down the flow such that the user confirmation is sent immediately after prechecks.
• Also ensure that core customer & account creation continue & conclude
• Future capability additions Monitoring & Recommendation are non intrusive

9. Event-Driven Choreography Architecture

10. Technical Implementation
Event-Driven Choreography
• Onboarding Customer -
i. After prechecks pass, EntityMgt Msvc publishes new entity txn to Kafka “new_entity_initiated_topic”
ii. Next, EntityMgt Msvc immediately sends back an initial user confirmation
iii. CustomerMgt Msvc subscribes to the Kafka “new_entity_initiated_topic”
iv. Consumes this event & creates the new customer entity
v. Publishes this event to Kafka “new_customer_created_topic”

11. Technical Implementation (contd..)
Event-Driven Choreography
• Onboarding Account -
i. AccountMgt Msvc subscribes to Kafka “new_customer_created_topic”
ii. Consumes this event & creates the account for this customer in the system
iii. Publishes this event to the Kafka “new_account_created_topic”

12. Technical Implementation (contd..)
Event-Driven Choreography
• Future Capability Efficiency -
i. Supporting msvcs Monitoring & Recommendation subscribe to Kafka “new_account_created_topic”
ii. Eliminates tight coupling & explicit invocation between services
iii. Asynchronous system requires a new Notification Msvc to send final confirmation to the customer
iv. This new svc is hooked up with ease by simply subscribing to the Kafka “new_account_created_topic”

13. New Architecture Positives
1. Significant improvement in system responsiveness to the customer
2. Elimination of tight coupling & explicit new service call invocations
3. The system only needs to know the topic to publish or subscribe to
4. Tremendous future flexibility as new services integrated by simply subscribing to the right topic

14. New Architecture Negatives (hidden landmines)
1. With the improved flexibility comes higher system complexity
2. Major infrastructure enhancement for event driven processing
3. Requires robust messaging components
4. Observability & tracing need significant ramp up for system debugging in failure scenarios
5. State management, retries and system wide rollbacks become complex
6. Requires elaborate SAGA implementation (will be covered in the next article) for system atomicity

15. Summary : Architecture, TechStack & Rationale
Github : https://github.com/vijayredkar/event-driven-platform
Architecture Goal Strategy Techstack Rationale
Flexible & extensible integrations Choreography Topics Eliminates centralized coordinator dependency
Event driven capability Messaging systems Kafka Eliminates tight coupling btwn svcs
Future capability efficiencies Publish/Subscribe Kafka Eliminates explicit new svc call invocation
System wide observability Centralized logging/tracing ELK/Sleuth Async logging & observability
Heavy volume/TPS Streaming Kafka/Async operations Extremely low latency
Parallel Aggregation CompletableFuture Java General purpose
Framework microservices Springboot General purpose

16. Thank you!
-Vijay Redkar
Github: https://github.com/vijayredkar
Medium: https://vijayredkar.medium.com/
vijay0512@yahoo.com