Does the WSO2 topology match the traffic it actually carries?

Overview

WSO2 deployments are frequently sized from a reference architecture chosen at install time and never revisited. Traffic patterns change, tenants get added, and the gap between the deployed topology and the workload shows up as instability rather than as a clear capacity signal.

Challenge

The deployment ran the control plane and gateway on shared nodes, put all component databases on a single instance without separation, and had a high availability story that had never been tested. Traffic had grown considerably and shifted toward long-lived streaming connections that the original sizing did not anticipate.

Environment

WSO2 API Manager on Kubernetes with a shared database tier, fronting parcel tracking and partner integration APIs.

Approach

AceMQ profiled real traffic characteristics — connection duration, payload size, burst shape — and compared them against the deployed topology and resource allocation. We then tested the high availability claims by deliberately failing components rather than accepting the architecture diagram at face value.

Solution

• Profiled real traffic shape including connection duration, payload size, and burst characteristics
• Separated control plane and gateway workloads onto appropriately sized node pools
• Recommended database separation and sizing per component against measured query load
• Failure-tested the high availability configuration by deliberately killing each component tier
• Reviewed the Kafka-backed event flow between gateway and traffic manager for capacity headroom
• Delivered a sizing model tied to measured traffic rather than the original reference architecture

Outcome

Technologies