Financial Services MSA Transition: Handling Asynchronous Message-Based Communication Between Servers (Part 3)

The FINDA asset/credit management PT judged that in an operating environment where large volumes of traffic converge, synchronous communication alone made it difficult to secure processing efficiency and stability, and transitioned to an asynchronous structure based on EDA (Event Driven Architecture) that reduces dependencies between servers.

There were three key choices.

• Apache Kafka: a Produce/Consume channel for asynchronous message delivery between servers
• Redis: Pub/Sub and Distributed Lock for handling server scale-out in SSE communication
• SSE: a method for delivering one-way events to the client

After comparing Polling, Long Polling, and WebSocket for the real-time event delivery method, they concluded that SSE was the most suitable. For one-way update flows like MyData lookups, where the client sends a request and the server retrieves the result, SSE was simpler and better suited to the purpose than bidirectional communication. They also noted that without HTTP/2, there is a limit on the number of browser connections.

The architecture was designed with the following flow.

1. The client creates an SSE connection to the AMS API, and Redis is used to check for duplicate calls.
2. The loan/deposit management server sends a message to the Kafka topic to the MyData management server, requesting a Refresh.
3. The loan/deposit management server responds with the cache first, and when the asynchronous result arrives, delivers it again via SSE.
4. The MyData management server exchanges requests/responses with the Worker via Kafka, and uses a Redisson-based Distributed Lock for state management.
5. The Worker communicates with the external MyData portal or financial companies to collect the actual data.
6. The final response is consumed again via Kafka and stored in the DB and Redis.

In particular, code snippets such as getLmsAccountListByAsync, send, hincrByLock, and loanRefreshResponseListen show that the process from request intake to result reflection was broken down into a message-based asynchronous flow. As a result, clients can now render screens without having to distinguish whether data is cached, and the direction is clear: reducing the problem of slow inter-server API calls blocking the entire request processing path.