Understanding WSO2 API Manager Deployment patterns

WSO2 API Manager comes with a modularized architecture so that users can scale the components based on their needs. When scaling the WSO2 API manager deployments, it is essential to understand the interconnections between different components. As depicted in the below figure, WSO2 API Manager has 6 main components.

Source: https://docs.wso2.com/display/AM210
  • Publisher — Creates and Publish APIs and manage API lifecycle
  • Developer Portal (Store) — Discover APIs, Subscribe to APIs, Test APIs
  • Gateway — Process the API requests. Traffic handling component
  • Key Manager — Validate the authenticity of the requests (traffic) coming into the gateway
  • Analytics — Provide analytics on API usability
  • Traffic Manager — Provide throttling and rate limiting of API access

The interconnections of these components happen through database, user store(LDAP) sharing. The interconnections are depicted in the below figure.

Source: https://docs.wso2.com/display/AM210

As depicted in the above figure, once the API is created and published from the API publisher, meta data will be push into the registry database. From that, API developer portal will get the meta information and show them in the portal. In the meantime, API file will be deployed to API gateway through the web service (admin service) call from publisher to gateway. If there are any throttling policies attached to a given API, that information will be pushed to the traffic manager. User information will be shared through user management database as well as user store (LDAP). When an API user generates a token for his application, that information will be stored in the API management database which is shared across publisher, dev portal and key manager. When the application sends an API call to the gateway, it will call the key manager and validate the token using the API management database.

Those are basic information about the componentized architecture and how they interact with each other during an API creation, publishing, subscription and invocation process. When these components are distributed for scalability, these interconnections needs to be maintained using relevant database sharing options mentioned above.

WSO2 API Manager All-in-one deployment

This is the simplest deployment pattern which can be setup using the WSO2 API Manager and APIM Analytics components. This is suitable if you have a considerably low traffic requirements (<1000TPS) and need not to worry about scalability as such. The deployment would be 2 All-in-one nodes in active/active mode with one APIM analytics node.

Source: https://docs.wso2.com/display/AM210/Deployment+Patterns

If you are going with this approach, it is essential to deploy the load balancer in DMZ and put the APIM deployment within LAN as depicted above.

WSO2 API Manager partially distributed deployment

The next level of deployment pattern is to partially distribute the API manager components so that scaling and non-scaling profiles are separated. In WSO2 APIM, we have 3 major scaling components

  • Gateway
  • Key Manager
  • Traffic Manager

Compared to Gateway and Key Manager, Traffic Manager scales at a low rate (10:1) and hence we can consider that as a non-scalable component. Due to that reason, If you need some kind of scalability while keeping the setup less-complex with less costly, you can use the partially distributed deployment mentioned in below figure.

Source: https://docs.wso2.com/display/AM210/Deployment+Patterns

In the above mentioned setup, Key Manager and Gateway components are installed in separate JVMs while Publisher, Store and Traffic Manager components are installed in the same JVM. If you need to further scale down this solution, you can think of keeping both Gateway and Key Manager nodes combined into one JVM so that you can further reduce the number of nodes by 2. But that is optional.

WSO2 API Manager fully distributed deployment

If users need the full control of the WSO2 API manager deployment with scalability, users can utilize the fully distributed deployment as depicted in the below figure. In this setup, all the components are deployed in separate JVM instances and based on the requirements, scaling profiles can scale up and scale down.

Source: https://docs.wso2.com/display/AM210/Deployment+Patterns

WSO2 API Manager Internal/External deployment

If your organization needs to separate out the internal and external API gateways, that can be achieved by using this deployment pattern. In this setup, there is only one API publisher which is publishing the APIs. There are separate gateways for handling internal and external traffic.

Source: https://docs.wso2.com/display/AM210/Deployment+Patterns

When publishing the APIs, users can select which gateways to be published the API and the store will only display the APIs relevant to specific tenants which are accessible from outside.




This publication contains best practices, examples and guidelines for WSO2 users.

Recommended from Medium

Relé 1.0.0 🚀

“My Experience With Problem Solving So Far”

GoFrarme 101: Add ratelimit middleware

CIDOC vs Solr — Steamrolling your model

What you need to write a crypto trading bot — part 2

Keeping your API tokens fresh

Don’t be a quitter!: Number of Games Played and Win Rate in League of Legends


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chanaka Fernando

Chanaka Fernando

Writes about Microservices, APIs, and Integration. Author of “Designing Microservices Platforms with NATS”

More from Medium


Designing workflows in Microservices (Foundation of Event-Driven Architecture)

Kafka Stream Microservice Sizing Recipe

Database per service or shared database?