Architectures
APIM Deployment in DEV/STG/PRD Environments
In this architecture, the APIM platform is deployed on a Kubernetes cluster and segmented by namespaces and roles. The system is designed to run independently across multiple environments such as Development, Staging, and Production.
Ingress Layer and External/Internal Routing
At the top layer, the system utilizes two Load Balancers (LBs):
Internal LB (Admin Access) - provides access to:
- APIM Console (apim-admin.company.com)
- IAM Console (tenant-admin.company.com)
- Developers Portal for admin (developers-admin.company.com)
- Auth Console (auth-admin.company.com)
Internet-facing LB (User Access) - provides external access to:
- Open API services (api.company.com)
- Public Developer Portal (developers.company.com)
Traffic is routed through a centralized Ingress Controller, where TLS termination occurs, and traffic is forwarded over HTTP to internal services based on domain paths.
Node Group: Management
This group hosts all core components required to manage tenants, projects, gateways, APIs, and policies.
Key Namespaces:
namespace: apim
Core Components:
| Component | Description |
|---|---|
| Tenant Manager (IAM) | Handles identity and access management for system users and tenant organizations |
| Tenant Manager Console | UI frontend for tenant admins (built with Vue.js) |
| API Management Console BFF | Backend-for-Frontend coordinating UI and service interactions (Vue.js & Node.js) |
| Gateway Manager | Controls gateway provisioning and association with projects |
| Policy Manager | Manages inbound/outbound policy definitions such as IP filtering, authentication, logging |
| Developers Portal (Frontend & Backend) | Interfaces for API users to browse and test published APIs |
| Analysis Manager | Handles real-time API usage analysis and reporting (connected with FluentBit) |
Persistent Databases:
- Tenant Manager DB (PostgreSQL)
- APIM DB Master/Slave (MariaDB)
- PVC configured for data durability and redundancy.
Node Group: User-Node-Group
This group executes runtime API traffic and routes user API calls to backend microservices.
Namespaces:
namespace: user-namespace
Components:
| Component | Description |
|---|---|
| API Gateway | Kong-based gateway handling ingress API requests |
| API Gateway DB | PostgreSQL store for runtime gateway configuration and state |
| In-Memory DB (Master/Slaves) | Used for token/session storage (likely Redis or similar) |
| Microservices | The actual backend services receiving routed API traffic |
API Gateway receives requests from external users and performs:
- Policy execution (auth, IP filtering, etc.)
- Routing to appropriate microservice
- Returning responses back via the ingress
Node Group: Monitoring
| Component | Description |
|---|---|
| Logging System | Powered by Elasticsearch, used for collecting structured API logs |
| Monitoring System | Powered by Prometheus, collects metrics for system health and alerting |
Logging and monitoring components are integrated with FluentBit and API Gateway logs, enabling:
- Real-time API traffic insights
- Custom metric visualization
- Alerting via Slack/Email channels
System Communication Flow
- Admins access the system via internal domains through the Ingress Controller.
- Users call Open APIs and Developer Portal via external domains, which route to the Kong Gateway.
- Kong enforces API policies (inbound/outbound) and routes to respective microservices.
- Logs and metrics from all components are streamed to the monitoring and logging stack.
Integrated APIM Deployment with Cloud & Third-Party Services
This architecture shows how the APIM system integrates with external infrastructure such as AWS and logging/monitoring services like CloudWatch, Datadog or Firehose.
How It Works:- External users access the system through a public domain, which is routed via AWS API Gateway through VPC Link to Internal APIM Gateway.
- Private domains and Route53 are used to route requests internally to the Kubernetes cluster where APIM services reside.
- Once requests reach the Kong Gateway, inbound policies are enforced (authentication, header injection, etc.), and then traffic is routed to backend services.
- Responses pass through outbound policies (e.g., data masking, logging), and are returned to the client.
- All request/response logs and metrics are forwarded to CloudWatch, Datadog, or Firehose via integrated exporters.
- Swagger-based spec registration is used to expose or update APIs dynamically through Dev Portal.
This architecture supports secure, scalable, and observable API management across organizational boundaries. It ensures API governance while allowing seamless extension to cloud-native services.
Internal Deployment for Development Environment
This version reflects an internal-only setup of the APIM platform for development use. It emphasizes security and closed access during API testing or service development.
How It Works:- All traffic flows internally, through private DNS and ALB, into the cluster.
- Internal developers access the APIM Console, Developer Portal, and IAM via predefined internal subdomains.
- API traffic from development frontend applications is sent to the Kong Gateway, where all configured policies are applied.
- Backend microservices (hosted in the bo namespace) respond to requests routed through the gateway.
- The entire stack is separated by namespace for maintainability and role separation:
- apim contains configuration and control logic.
- microservices contains runtime services and business logic.
This architecture allows safe API development and testing without any exposure to public networks. It is optimal for validating services, applying policies, and verifying access control before staging or production rollout.
Dev-Only Internal Flow Model
This architecture presents a detailed internal traffic flow within a development environment, focusing on network boundaries and isolation.
How It Works:- Internal applications and developers interact with the APIM Console or Developer Portal through private domains and NLB/ALB routing.
- Requests from the frontend are routed to the Kong Gateway, where runtime policies such as authentication, rate limiting, and transformation are enforced.
- Gateway routes requests to backend microservices hosted in the same cluster or via service mesh (if applicable).
- API usage, logs, and traffic statistics are sent to internal observability tools like Datadog, ensuring visibility during dev operations.
- There is no public-facing access point in this environment - all components, including the API Gateway, are strictly internal.
This setup ensures a secure, isolated pipeline for developing and testing APIs while retaining full monitoring and governance capability. It allows dev teams to simulate production-like API behavior without external exposure.
Component Description and Resource
This table outlines the CPU, memory, and storage resources assigned to each component in the APIM Control Plane. It helps infrastructure and DevOps teams plan and provision Kubernetes clusters accurately and efficiently.
| Instance | Description | kind | Replicas | CPU (m) | CPU Total (m) | Memory (Mi) | Memory Total (Mi) | Storage (GB) | Storage Total (GB) |
|---|---|---|---|---|---|---|---|---|---|
| deploy-apim-analysis-manager | Analysis Manager | Deployment | 1 | 0.5 | 0.5 | 1024 | 1024 | 0 | 0 |
| deploy-apim-bff | APIM Console BFF | Deployment | 1 | 0.5 | 0.5 | 512 | 512 | 0 | 0 |
| deploy-apim-gateway-manager | Gateway Manager | Deployment | 1 | 0.5 | 0.5 | 768 | 768 | 0 | 0 |
| deploy-apim-tenant-manager | Tenant Manager (IAM) | Deployment | 1 | 0.5 | 0.5 | 768 | 768 | 0 | 0 |
| deploy-apim-tenant-manager-console | Tenant Manager Console | Deployment | 1 | 0.2 | 0.2 | 512 | 512 | 0 | 0 |
| deploy-apim-policy-manager | Policy Manager | Deployment | 1 | 0.2 | 0.2 | 512 | 512 | 0 | 0 |
| deploy-apim-developer-portal-backend | Developer Portal Backend | Deployment | 1 | 0.2 | 0.2 | 512 | 512 | 20 | 20 |
| deploy-apim-developer-portal-frontend | Developer Portal Frontend | Deployment | 1 | 0.2 | 0.2 | 64 | 64 | 0 | 0 |
| deploy-apim-mariadb-master | APIM DB (MariaDB Master) | StatefulSet | 1 | 0.5 | 0.5 | 512 | 512 | 10 | 10 |
| deploy-apim-mariadb-slave | APIM DB (MariaDB Slave) | StatefulSet | 1 | 0.2 | 0.2 | 256 | 256 | 0 | 0 |
| statefulset-apim-tenant-manager-postgresql | IAM DB (PostgreSQL) | StatefulSet | 1 | 0.5 | 0.5 | 256 | 256 | 10 | 10 |
| Total | 4 | 5760 | 40 |
- CPU: 4 Cores
- Memory: 6 GiB
- Storage: 40 GB
Notes:
- CPU/Memory increases depending on replica scaling policy
- Logging/Monitoring storage scales with traffic volume
- One public and one private APIM deployment are supported