Background of API and Kong Gateway Implementation

1. New Feature Requirements: Data Integration and Statistical Processing Between Heterogeneous Systems

Recently, a new feature has been added to the service I am in charge of. It was a function that directly fetches data dispersed across other systems, refines it to fit the purpose of our service, and intuitively presents statistical data to users.

To implement this feature, there were two key tasks.

• Ensuring Data Reliability: It was necessary to reliably call APIs from other systems and to integrate large amounts of data without loss.

• Minimizing Coupling: There was a need for a loose coupling structure that minimizes the impact of changes in other systems on our service.

1.1 Why Kong API Gateway? (Adopting Internal Architecture Standards)

When exposing new API endpoints and designing communication with other systems, our team decided to utilize the company's standard architecture policy, 'Kong API Gateway',because leveraging an already well-established internal infrastructure provides powerful technical advantages beyond mere compliance with rules.

• Centralized Routing Management: By unifying the entry points of new endpoints with Kong, we can reliably maintain the external interface even if the service expands in the future or the internal URL structure changes.

• Delegation of Common Functions: By delegating common functions required for API security and management, such as Authentication, Authorization, and Rate Limiting, to Kong's plugin ecosystem, we can focus solely on business logic (data cleanup and statistical calculation) without having to implement them individually at the application level.

• Monitoring and Traffic Control: It was the optimal choice to centrally monitor the status of traffic coming in or going out from other systems and to ensure availability.

As a result, this task was "Implementing business logic to securely bring in data from other systems and process it into statistics internally"and "Seamlessly integrating this with Kong Gateway, our internal standard architecture, to secure a stable service endpoint"was the key.

2. Key Concepts of Kong API Gateway and Routing Configuration

2.1 The 3 Core Objects of Kong Every Backend Developer Should Know

Kong Gateway allows developers to intuitively understand complex proxy and routing configurations.Service, Route, ConsumerWe abstract and manage this as three core objects (Entities). Let's take a look at how these concepts were mapped to connect this new feature, along with examples.

[외부/타 시스템 요청] ──> [ Route (/api/v1/realtime-analytics) ]

                      │ (토큰 검증: Consumer 인증)
                      ▼
            [ Service (internal-stats-cluster) ] ──> [실제 백엔드 API]

1) Service (Internal Service Definition)

• conceptKong is forwarding traffic Actual backend application (Upstream address)It means that you configure the IP or domain of the internal physical server, timeout policies, etc. at this stage.

• exampleA separate service will gather data from another system and process statistics using an internal Spring Boot/Node server (http://internal-stats-cluster.local).

2) Route (External Entry Point Definition)

• concept: external clients or other systems Endpoint (path, domain, HTTP method, etc.) to use when accessing Kong GatewayIt means. One Service can have multiple Routes.

• exampleThe public URL path /api/v1/realtime-analytics that external systems use to request real-time statistics will be the Route.

3) Consumer (User/Target System Definition)

• Concept: Refers to theentity (client, app, or other systems)that consumes the API. Kong can map authentication tokens or enforce traffic limiting (Rate Limiting) at the Consumer level.

• Example: An external ‘data consumption system (external-data-consumer)’ that calls our system's API to retrieve real-time statistical data is registered as a Consumer.

2.2 Collaborative Architecture for Application-Based Token Issuance and Gateway-Based Validation

To ensure secure data transmission between heterogeneous systems, this real-time statistics feature was developed on a Declarative Configuration environment,"Token issuance centered around backend logic and fast validation centered around the gateway"adopts a hybrid architecture.

Precise business rules, such as token issuance and expiration time management, aredirectly implemented as internal logic of the backend applicationto control. On the other hand, the validation of real-time API requests that come with already issued tokens is handled by the front-lineKong Gateway layer (JWT plugin)Structured to intercept and execute.

This structure was an architectural choice to protect the CPU resources of our backend system, which needs to perform real-time large-scale statistical calculations, and to maximize availability beyond mere convenience.

• Separation of Concerns: The business logic of the token is handled by custom backend logic, while packet filtering and signature verification at the network frontline are handled by Kong. Thanks to this, the backend can focus solely on the inherent business logic of 'statistical calculations and data refinement.'

• Trust Chain through Shared Secret: By synchronizing the secret key used by the backend to sign the token and the key used by Kong Gateway to verify the signature, we implemented a high-speed distributed authentication environment without the overhead of querying a heavy authentication server each time.

• Resource Optimization for Real-Time Statistics: Since Kong blocks invalid requests with abnormal tokens at the front end with a 401 Unauthorized response, we were able to prevent unnecessary resource waste in the backend application that performs large-scale statistical calculations.

3. Troubleshooting: The infrastructure is perfect, but the traffic has disappeared? (Debugging missing application bean registration)

3.1 The infrastructure is normal, but there is no response from the backend

After completing the virtual declarative configuration on Kong Gateway, I perfectly implemented token-based real-time statistical API backend code in accordance with existing internal guidelines and logic rules. Since all infrastructure routing lines were aligned, I naturally expected it to connect immediately.

However, at the moment of conducting end-to-end (E2E) testing by calling the API endpoint through Kong in the local development environment, requests either vanished midway or failed to locate the backend internally instead of the expected statistical results.

[Client Request] ──> [Kong Gateway (Passed)] ──> [Backend Application (Connection Lost)]

At first, I believed it was a routing issue at the gateway due to Kong's strip_path setting or header forwarding problems, or that the shared secret key was mismatched, and I focused on debugging the infrastructure logs and container networks. However, Kong was accurately routing packets to the backend target server. The problem was not with the gateway but inside our backend applicationwas.

3.2 Cause Analysis: Missing Bean Registration in the Framework Lifecycle

The cause is ironically the most fundamental and core backend concept.'Bean registration missing'was.

While focusing solely on writing a new service class for processing real-time statistics and the token validation handler/interceptor logic according to the architectural rules and framework specifications of the existing internal system, I missed registering the relevant objects with annotations (e.g., @Service, @Component) so that the Spring IoC container could manage them or specifying them as beans in the configuration files.

At the time of application execution, the controllers or interceptors of the corresponding domain are not loaded properly, so even if Kong Gateway sends real-time traffic to the correct internal address, the application layer does not have a context to handle it, which can result in request loss.

3.3 Solutions and Lessons Learned

After identifying the cause, the newly added data refinement and statistical operation business logic class Specify the missing @Service annotation to properly register the bean in the IoC containerThank you.

//Example:Register the misiing bean annotation in the IoC container
@Service
Public class RealtimeStateProcessingServie implements StateServie {
   //Logic for collecting data from external systems and processing real-time statistics

}

Once the dependency injection (DI) was successfully implemented, we confirmed that when calling the test API in the local environment, the traffic flowed smoothly through Kong's JWT validation to the backend internal logic in one go.

This troubleshooting reminded me that regardless of how smoothly the communication lines are established in the infrastructure (Kong Gateway) area, the core component scanning and lifecycle management of the backend application that accommodates this must clearly align for a large distributed system to function organically.

4. Conclusion: Lessons Learned from the First Kong Gateway Integration

This project is important to me 'Experience in evolving backend architecture using existing internal infrastructure'It was a meaningful opportunity that was presented to me. Even though the Kong Gateway environment was already set up at the company, I had not had the chance to handle it directly until now, so the process of routing a new URL and integrating the token layer for the first time was a strange and fresh challenge.

At first, I simply thought of the API Gateway as a device that "connects network paths," but I was able to directly experience how powerful a weapon it can be from the perspective of a backend developer.

• It handles the heavy authentication verification layer that the backend had to implement directly at the forefront.Efficiently protecting the CPU resources of the applicationcould

• Thanks to that, I only refine the data from other systems and calculate accurate statistics.Focus only on the 'core business logic'I was able to.

Although I experienced a minor oversight of missing registrations during the local testing process, this debugging process allowed me to broaden my perspective on the application framework from an infrastructure-aware standpoint.

I have learned that skillfully leveraging the powerful common plugin ecosystem provided by the infrastructure is also a core competency of a backend engineer. In the various new microservices features to be built in the future, I will actively combine the resources of Kong Gateway, the internal standard, to design a scalable and robust system architecture.

kina.j