What’s new with WSO2 APIM 3.2.0 Part-1

In-Memory subscription validation

The In-Memory subscription validation provides support to remove runtime dependencies between the Gateway and the Key Manager node and validates the request by accessing the metadata in the In-Memory data store. This is a major improvement for APIM 3.2.0. As a result, the WSO2 API Manager can serve the request even in a situation where the database is inaccessible.

How APIM 3.1.0 and before handled Key Manager interactions?

The challenges had with the previous releases was;

APIM 3.1.0 or before
  1. Gateway scaling limitation; Yes, there were potential practice issues, there was the problem of tight coupling of the DB at Key Manager, there was a problem when GW communicates with the Kay manager direct and if DB fails, the whole operation would be in jeopardy (at least for a short period of time, but still this is significant for critical operations).
  2. Also, to reduce DB operations interactions, there were multiple caching layers built on top of Key manager components because of deployment expansions.
  3. Scalability becomes issues with Gateway expansion with the number of Key manager operations the Key manager layer had to deal with an ever-growing load (note: with DB bottleneck due to huge read writes)
  4. Gateway’s dependency with the key manager; Whenever the key manager component released, the underneath admin communication for a different type of Key manager activities were depended on the Key Manager component, again, this was another major factor faced with the Key Manager scalability

How APIM 3.2.0 revamp its architecture?

APIM 3.2.0 revamp architecture of the in-memory

APIM 3.2.0 and beyond

  1. With the new implementation, the gateway is responsible for validating the token or validating the scope in memory.
  2. The in-memory maps keep the contexts of the subscriptions, applications, APIs, Scope, Policies. When requests come the validation happens using the in-memory maps. These maps are basically in-memory hash maps, with this way, it reduces the connection between the key manager
  3. The direct link between the gateways and the key manager eliminated with the hub and spoke model or we call it event-driven architecture. The EventHub. a.k.a TrafficManager plays the key role in establishing notification between other critical nodes loosely coupled manner
  4. Yes, this architecture has proven, how it would boost the overall platform performance, especially when comes to key validation, scope validation

How event-driven notification improved the key subscription architecture?

Artifact event notification and updates at Gateway nodes
Gateway node scalability

Key points

APIM 3.2.0 distributed architecture of event notification
  • Overall, as depicted the APIM 3.2.0 and beyond offers a loose coupled event-driven architecture that will address most of the issues that developers noticed during APIM 3.1.0 or before and around Key Manager direct invocation via Gateway nodes
  • You'll notice right now, APIM 3.2.0 and beyond the Traffic manager should communicate with the AM_DB, the reason as stated, whenever changes notified traffic manager will query (read-only mode) the AM DB and provides a relevant update.



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