Over a million developers have joined DZone.

Understanding WSO2 API Manager Deployment Patterns

DZone's Guide to

Understanding WSO2 API Manager Deployment Patterns

A discussion of the several different ways that developers can manage and deploy WSO2 APIs, and what situation each is best suited for.

· Integration Zone ·
Free Resource

WSO2 is the only open source vendor to be named a leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. Download the report now or try out our product for free.

The 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.


  • Publisher - Creates and Publishes APIs and manages API lifecycles.
  • 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.


As depicted in the above figure, once the API is created and published by the API publisher, metadata will be pushed into the registry database. From that, the API developer portal will get the meta information and show it in the portal. In the meantime, the API file will be deployed to the API gateway through the web service (admin service) call from the publisher to the 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 a user management database as well as a 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 the 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.

That's the basic information about the componentized architecture and how it's various parts interact with each other during the process of creating, publishing, subscribing to, and invocating an API. When these components are distributed for scalability, these interconnections need to be maintained using the 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 considerably low traffic requirements (<1000TPS) and need not worry about scalability as such. The deployment would be two, all-in-one nodes in active/active mode with one APIM analytics node.


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 and less costly, you can use the partially distributed deployment mentioned in below figure.

In the above-mentioned setup, the Key Manager and Gateway components are installed in separate JVMs while the 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 two. 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.


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.

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

IAM is now more than a security project. It’s an enabler for an integration agile enterprise. If you’re currently evaluating an identity solution or exploring IAM, join this webinar.

integration ,api ,api management ,api deployment

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}