Architecture of an IPDB Node

An IPDB Production deployment is hosted on a Kubernetes cluster and includes:

../_images/arch.jpg

Note

The arrows in the diagram represent the client-server communication. For example, A–>B implies that A initiates the connection to B. It does not represent the flow of data; the communication channel is always fully duplex.

NGINX

We use an NGINX as HTTP proxy on port 443 (configurable) at the cloud entrypoint for:

  1. Rate Limiting: We configure NGINX to allow only a certain number of requests (configurable) which prevents DoS attacks.
  2. HTTPS Termination: The HTTPS connection does not carry through all the way to BigchainDB and terminates at NGINX for now.
  3. Request Routing: For HTTPS connections on port 443 (or the configured BigchainDB public api port), the connection is proxied to:
    1. OpenResty Service if it is a POST request.
    2. BigchainDB Service if it is a GET request.

We use an NGINX TCP proxy on port 27017 (configurable) at the cloud entrypoint for:

  1. Rate Limiting: We configure NGINX to allow only a certain number of requests (configurable) which prevents DoS attacks.
  2. Request Routing: For connections on port 27017 (or the configured MongoDB public api port), the connection is proxied to the MongoDB Service.

OpenResty

We use OpenResty to perform authorization checks with 3scale using the app_id and app_key headers in the HTTP request.

OpenResty is NGINX plus a bunch of other components. We primarily depend on the LuaJIT compiler to execute the functions to authenticate the app_id and app_key with the 3scale backend.

MongoDB

We use MongoDB as the backend database for BigchainDB. In a multi-node deployment, MongoDB members communicate with each other via the public port exposed by the NGINX Service.

We achieve security by avoiding DoS attacks at the NGINX proxy layer and by ensuring that MongoDB has TLS enabled for all its connections.