3scale systems are accessible in a variety of different ways by deploying control points (also known as agents) in locations where they can enforce traffic policies. There are four different deployment patterns which are commonly used – three are shown in the figure below and the fourth (deployment by API) is a variant of the plugin method.

In general only one method is chosen per deployment – but for complex installation with different APIs or unusual needs deployment methods can be mixed and used together in combination.

The four deployment methods are:

  • Plugins : the simplest deployment mode is to use one of the numerous native language plugins 3scale provides. These libraries are added to API application code to enforce traffic policies at the point of traffic entry. Libraries are available in languages such as Ruby, Python. .Net, Java and PHP. Libraries call 3scale APIs in either synchronous or asynchronous mode.
  • Proxy Deployments : in this mode, instead of deploying the control elements in the API application stack, they are deployed in supported open source proxies which can be set up in front of the API and act as a traffic filter gateway for API calls. The recommended proxy is Nginx, for which 3scale will automatically generate the necessary configuration. Nginx offers a high performance solution that does not require any change to your API code. This solution also provides a caching mechanism that optimizes the performance of the integration with the 3scale platform.
  • CDN Deployments : for media and content heavy APIs, 3scale integrates with global CDNs such as AKAMAI in such a way that all API traffic can be directed at CDN edge nodes and still have API access control, policies and rate limits enforced as well as collecting API Analytics.
  • API Deployments each of the methods above is effectively a wrapper of 3scale’s own Service Management API designed for easy deployment. However, custom and bespoke deployments can integrate with the API directly – allowing you to integrate 3scale services in whatever manner suits you best.

In addition, deployment may be synchronous or asynchronous in nature – giving you full control of how 3scale infrastructure is invoked for your API.

Plugin based deployment

3scale provides code plugins in multiple languages which can be deployed in any application to add API control. The installation pattern for each library depends on the specific programming language in use (instructions are available in each bundle). However, as an overview – each plugin implements:

  • Authentication calls to check only issued and non-suspended keys can access the API.
  • Verification that rate limits are not exceeded.
  • Traffic reporting to provide usage information into the 3scale analytics and rate limit components.

If you’re working in a framework which isn’t currently supported let us know (via the forum or email and we’ll let you know if there’s anybody actively working on support.

Proxy based deployment

A second way to add control to your API is using a proxy deployment in front of your application to filter traffic as it arrives. 3scale recommends using Nginx for this purpose. In order to set up API control with Nginx only three simple steps are needed:

  • Download and install Openresty, an Nginx bundle that includes all required dependencies.
  • Configure your API details in the 3scale dashboard and download the Nginx configuration files
  • Run Nginx with the new configuration files and you are ready to go

If you have multiple physical locations which serve traffic then you can also set up Nginx instances at each locations – 3scale’s systems will act as synchronization points for key management and rate limits between all these locations.

3scale also supports using the Varnish caching proxy as an alternative to Nginx. More information about that option is available in the Varnish as an API Proxy tutorial.

CDN based deployment

3scale supports connection to a number of different CDN infrastructures including Akamai. This architecture enables you to serve all API traffic via CDN edge nodes without the need for calls back to origin servers when caching is enabled. Hence API traffic can be served directly from caches closest to your API users and still enforce all the normall API access controls.

Setup for CDN integration varies by CDN but the overall architecture follows the pattern shown in the figure below.

For help with CDN setup contact us by email.

API based deployment

Each of the methods above is effectively a wrapper of 3scale’s own Service Management API. For more flexibility, the API can also be called directly from anywhere. See the documentation for details.

Synchronous vs Asynchronous Deployment

3scale’s architecture supports both synchronous and asynchronous traffic management approaches:

  • In synchronous mode, plugins or agents make calls to 3scale for each API call that reaches them in order to validate API Keys and report traffic.
  • In asynchronous mode, plugins or agents retain a local cache of currently live API keys and serve traffic based on the content of this cache. This caches is the update asynchronously in the background to keep policy and usage rate information current.

Synchronous mode is easy to set up and effective at low and medium volumes. For high volumes, asynchronous approaches afford more control to the agent and reduce latency in API responses.

The majority of software plugins provide synchronous integration by default but can be modified for asynchronous operation. Proxy integration is by default asynchronous with either Nginx or Varnish keeping a local cache of keys and policies.

Multiple Locations

3scale places no restrictions on how many traffic agents are deployed or their physical locations. Hence if API traffic is served from multiple physical locations, agents would be deployed at each location in the appropriate manner. Access keys issued to developers are equally valid at all locations.

Mixing Deployment modes

In general you will only need one of the deployment methods for a given API (or set of APIs) but there are no constraints on adopting several if the needs of different APIs or customers vary. For example – traffic may arrive at your system from various ingress points based on type with some entering via a CDN and some coming direct. In these cases agents can be placed at all relevant entry points and use the same 3scale account seamlessly.

The primary thing to avoid in such scenarios is to ensure that a particular traffic call only passes through one reporting step (that control points are not cascaded).