Translated from the Korean original. Some screenshots show the original Korean interface.
Corporate service architectures keep getting more complex.
In the past, a user's request was often handled by one server and one database. Today, many systems, including web servers, WAS, API servers, DBs, message relay servers, and external institution systems, work together to form a single service. In financial institutions in particular, a single account transfer often passes through several internal systems and then communicates with other financial institutions or external agencies.
The trouble starts when a transaction slows down or an incident occurs. The monitoring system shows that response time went up, but finding where the actual cause lies is not easy, because you have to check every segment the transaction passes through, such as the WAS, the DB, and the links to external institutions, one by one. Operators end up collecting piles of logs and monitoring data and tracing the cause by hand, and incident analysis inevitably takes longer.
ย
ย
1. What is E2E transaction tracing?
E2E (End-to-End) transaction tracing identifies and tracks the entire flow of a user transaction, from start to finish, as one transaction. For example, when a user requests an account transfer in a mobile app, the transaction may go through the following steps.
ย
From an operations point of view, this whole process is one transaction.
From a system point of view, however, each step is handled as a separate request and response. E2E transaction tracing assigns a common identifier (Key) across all segments of the transaction to link multiple servers and communication segments into one flow. Operators can then see the transaction's full path and the response time of each segment on a single screen.
In other words, you don't just see that a transaction is slow; you can see "which segment was delayed, and by how much."
Communication between servers for transaction processing falls broadly into HTTP and Socket. Let's look at each in more detail below.
ย
1-1. E2E transaction tracing over HTTP
HTTP-based services are the most common form of communication today. InterMax E2E performs E2E transaction tracing over HTTP without any extra development work, automatically generating and propagating a unique identifier whenever one server makes an HTTP call to another.
Each server links the transaction using the same identifier.
So even in a complex service architecture that passes through many WAS and API servers, operators can easily trace a single transaction flow. In MSA (Microservice Architecture) environments especially, a single request often triggers dozens of service calls or more, and this kind of automatic E2E tracing over HTTP is highly effective there.
ย
1-2. Socket-based message communication and E2E transaction tracing
In finance, however, many workloads still use Socket-based message communication rather than HTTP.
That is because core operations such as account inquiries, transfers, approvals, and settlements are often processed with in-house defined messages. To link transactions, you have to use the unique transaction number (GUID) inside the message. In short, E2E transaction tracing is implemented differently depending on the communication protocol.
Using the standard message layout provided by the customer, the screen can also show the information needed for analysis, such as the transaction's GUID, transaction code, and transaction result.
InterMax E2E links the sending and receiving segments based on the GUID of the messages an application uses and assembles them into one transaction flow. This makes E2E transaction tracing possible even in the complex message-based communication environments typical of finance.
ย
ย
2. Why E2E transaction tracing matters in finance
Financial services are mission-critical systems with very low tolerance for incidents. In services tied directly to customer transactions, the time it takes to analyze the cause can be a bigger problem than the incident itself. Say a customer requests an account transfer and the response is taking more than 10 seconds. In that situation, the IT operations team must be able to answer the following questions right away.
- Which server is causing the delay?
- Is DB response time normal?
- Is the external institution slow to respond?
- Is there a bottleneck at the message relay server?
E2E transaction tracing answers these questions and helps greatly reduce MTTR (Mean Time To Recovery), the measure of how quickly incidents are resolved. As digital transformation and MSA adoption spread across finance, E2E transaction tracing is becoming a must-have rather than an option. By showing the full path a transaction took on a single screen, it lets operators quickly see in real time which transaction is the problem without manually cross-checking logs from multiple systems.
ย
Financial systems also complete a single transaction by exchanging data with many institutions, such as the Korea Financial Telecommunications & Clearings Institute, card companies, other banks, and credit rating agencies. As a result, it is not uncommon for internal servers and databases to work normally while communication with external institutions slows down and stretches the overall transaction time.
In these situations, it is important to quickly determine "whether the problem is in our system or in the external link." Ultimately, the purpose of E2E transaction tracing is not simply to link transactions but to improve service continuity.
ย
ย
3. Are distributed tracing and E2E transaction tracing the same thing?
In cloud and MSA environments, the term distributed tracing comes up often, with OpenTelemetry as the most widely used example. OpenTelemetry is very similar to E2E transaction tracing in that it tracks a single request as it passes through multiple services. In real financial environments, though, the following differences appear.
Category | General distributed tracing | Financial E2E transaction tracing |
Main environment | MSA, Cloud Native | Financial IT systems |
Communication | HTTP, REST, gRPC | HTTP, Socket messages |
Identification | Trace ID | GUID, transaction number |
Main purpose | Service call tracing | Transaction-level incident analysis |
That is why E2E transaction tracing, which links multiple systems and communication segments per actual business transaction rather than just following a Trace ID, matters.
ย
ย
4. Transaction tracing in InterMax E2E
One of the most important metrics for an operations team is MTTR. In the field, analyzing the cause often takes more time than the incident itself. Collecting logs, checking servers, inspecting the DB, and contacting staff at external institutions repeat over and over. With E2E transaction tracing in place, operators can instantly see the whole flow based on a single transaction. In the end, E2E is not just a monitoring feature but a core part of operations that cuts incident analysis time and raises service availability.
ย
ย
InterMax E2E goes beyond collecting application performance data and provides transaction-centric monitoring. It supports both HTTP links and Socket message communication, as required in financial environments, so you can trace a transaction as one flow from start to finish. Operations teams can see the following on a single screen.
- Visualization of the full transaction flow
- Response time analysis by segment
- Bottleneck identification
- Tracing of HTTP-based service links
- Tracing of Socket message transactions
- Analysis of external institution link segments
In complex service environments, linking scattered data into one transaction flow matters more than collecting more monitoring data, and E2E transaction tracing is where that linking starts.
ย
Even complex transaction flows on a single screen.
See InterMax E2E transaction tracing in action.
๐๐ป Explore InterMax E2E
๐๐ป Contact us
ย
ย
ย
ย
ย
ย
Related articles
