Skip to main content

Self-Hosted Architecture Overview

Self-Hosted Architecture

Services​

The Doconomy Enterprise Software (DES) is packaged as a single Docker/OCI container image, available on our container registry on quay.io (ask Customer Success for access).

The same image is used to run two process types (preferably in separate containers):

  • Web server: for serving the End User-facing Web App, DEPo and API traffic.
  • Background worker: for asynchronous workloads, such as running savehack logic and creating transactions.

Dependencies​

  • Postgres v11+ DB: for persistent storage.

  • s3: or any other s3-compatible object storage.

  • smtp server: DES uses verified emails as authentication for users of DEPo (the admin tool). An SMTP server is required to be able to send email verification and password reset emails.

  • Json Web Key Set (JWKS) endpoint: for fetching public keys to validate End User tokens.

External connectivity​

Depending on contract and which features are enabled, the DES backend hosted in your environment needs access to 2 services hosted externally in Doconomy's cloud environment:

API Aggregator​

For event / API-driven savehacks. An example is the SaveLeague savehack which needs access to live sports results. No End User data is shared with this service; it only provides publicly available event data, needed to run the savehacks in your environment.

Pseudonymized Usage Statistics Collector​

Doconomy rely on usage statistics to be able to continuously improve our product offering. Before any data is sent to Doconomy's cloud environment, it is pseudonymized by the DES Backend in your environment. In other words, before Doconomy receive the usage statistics, it is cleaned so that it can not be attributed to any specific End User unless combined with the DB in your environment.

Please contact Customer Success to get more information on Data Processing Agreements.

Subdomain-based Routing​

A single installation of DES can support multiple markets (or target audiences), with separate settings, content, and End Users through the concept called Partners. To enforce complete separation between different Partners across all the Web server endpoints (Web app, DEPo, and API), each Partner is hosted on its own subdomain under a common ROOT_URL (see Environment Variables).

For example, let's say that the DES installation should support two different markets, A and B with different needs in terms of localization, currency, content etc. This requires two Partners on different subdomains, in this example market-a and market-b. Furthermore, let's assume that DES is hosted on the domain awesome-bank.com and ROOT_URL is set to this value. Then,

  • End User requests are served from the Web app, given that the Host header equals market-a.awseome-bank.com or market-b.awseome-bank.com and the request path is anything under /.
  • Admin requests are served from DEPo, given that the Host header equals market-a.awesome-bank.com or market-b.awesome-bank.com and the request path begins with /depo.
  • API requests are served from the API, given that the Host header equals market-a-api.awesome-bank.com or market-b-api.awesome-bank.com and the request path begins with /v1.

NOTE the added -api suffix for API domains. This is to facilitate Host-header based routing and firewall rules to protect the API from being accessed from outside of your internal network.

See Fig. 2 for a schematic of this example setup.

Subdomain-based Routing

Figure 2: Subdomain-based routing for an example installation with two Partners market-a and market-b.

To enforce appropriate isolation between the Web app, DEPo, and API, and make sure that each endpoint is only accessible for it's intended audience, we recommend the following firewall rules.

NOTE: Order is important below; a block rule above an allow means block.

1. Block completely​

Endpoints not used in a self-hosted setup:

/field_test*
/flipper*
/internal*

2. Allow only from appropriate IPs within your backend network​

Endpoints for the backend API:

/v1*

3. Allow only from office network, VPN or similar​

Endpoints for the administration tools DEPo and MetaDEPo:

/depo*
/meta_depo*

4. Allow publicly:​

Various endpoints for the End User-facing Web App:

/*

Block all incoming traffic, but allow outgoing connections to the dependencies:

  • DB

Hardware Requirements​

The web service's memory footprint tends to vary in the range 300-500MB and the background job processing service's memory footprint normally sits around 300MB. The memory footprint is pretty stable regardless of cpu pressure, i.e. traffic volume.

We would recommend the following kubernetes/OpenShift resource settings for web and background services:

  • mem request: 500Mi
  • mem limit: 1Gi
  • CPU request: 500 milli-vCPU
  • CPU limit: 1000 milli-vCPU

With two replicas for each service (for high availability) you should be good to go (with good margins) for at least 100k monthly Active End Users. For these estimates, we are assuming the underlying node specifications are comparable to for example the Amazon EC2 M5a instance type.

Similarly, a DB with 2 CPUs/cores and 8GB of RAM and 30GB of storage should keep you well within margin for 100k monthly Active End Users.

File storage wise we recommend to plan for 50GB of initial storage, that should get you covered up to ~100k monthly Active End Users over a longer period (~1 year).