# Global architecture

# Overview

The typical global architecture and the underlying technologies of KDK are summarized in the following diagram.

Global architecture

# Architecture at scale

Although the typical architecture presented previously can be deployed in a single-server environment KDK has been developed as a loosely coupled set of modules to prevent it being a monolithic piece of software (opens new window). The built-in service layer (opens new window) helps decoupling the business logic from how it is being accessed based on a simple and unambiguous interface (opens new window). Kalisio applications can thus be deployed in a microservice architectural style (opens new window), which is typically used to provide high availability. The idea is to deploy different application instances on different logical hosts (can be physical machines as well as containers or virtual machines) each running the same or a different set of services.

However, you will have to face some scaling configuration issues (opens new window) first. You also have to setup the underlying logical infrastructure. To achieve high availability, different strategies may be used.


It is recommended to have a single source of truth (SSOT) for your data (i.e. a single database), simplifying authentication, which requires you to setup a MongoDB replica set (opens new window) and configure the DB URL accordingly (opens new window).

# Monolithic application

This is the easiest strategy, you can rely on Cloud-ready solutions like Kaabah (opens new window) to replicate and load-balance the different instances of your application and simply use feathers-sync (opens new window) to synchronize service events.


This approach is something between the true monolith and the true microservices architecture, i.e. you scale your entire application but not its underlying services according to their workload.

# Distributed application

You can split up your application API manually on a per-responsibility basis (e.g. each module on a dedicated instance) and just communicate with each other through Feathers clients using all the infrastructure that is already in place. You could also deploy a frontend application serving as an API gateway (opens new window). To configure the proxy rules, edit the proxyTable option in your configuration. The frontend server is using http-proxy-middleware (opens new window) for proxying, so you should refer to its docs for a detailed usage but here's a simple example:

// config/default.js
module.exports = {
  // ...
  proxyTable: {
    // proxy all requests starting with /api/service
    '/api/service': {
      target: 'http://my.service.com',
      changeOrigin: true,
      pathRewrite: {
        '^/api/service': '/api'

The above example will proxy the request /api/service/1 to http://my.service.com/api/1.

However, all of this requires manual work, creates a tight coupling with your underlying infrastructure and will not allow auto-scaling unless you have some discovery mechanism. You can make each instance automatically aware of others instances to distribute services and related events using feathers-distributed (opens new window).