Does the WSO2 topology match the traffic it actually carries?
WSO2
Kubernetes
PostgreSQLKafka
DockerThe failure testing exposed two single points of failure that the architecture diagram did not show, both of which were addressed. Sizing decisions are now driven by a measured model instead of the or…
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
- 1Profiled real traffic shape including connection duration, payload size, and burst characteristics
- 2Separated control plane and gateway workloads onto appropriately sized node pools
- 3Recommended database separation and sizing per component against measured query load
- 4Failure-tested the high availability configuration by deliberately killing each component tier
- 5Reviewed the Kafka-backed event flow between gateway and traffic manager for capacity headroom
- 6Delivered a sizing model tied to measured traffic rather than the original reference architecture
Outcome
The failure testing exposed two single points of failure that the architecture diagram did not show, both of which were addressed. Sizing decisions are now driven by a measured model instead of the original install-time assumptions.
Technologies
WSO2KubernetesPostgreSQLKafkaDockerRelated Use Cases
WSO2 API Manager Upgrade and Migration Consulting
Planning a multi-version WSO2 API Manager upgrade including registry migration, API redeployment, and identity integration changes.
WSO2 API Manager Throttling Consistency Remediation
Fixing throttling policies that applied inconsistently across WSO2 gateway nodes, letting some consumers far exceed their subscription tier.
Ready for a WSO2 Health Check?
AceMQ's senior WSO2 engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.