Platform Welcome Guide

Our comprehensive guide will provide you with answers to the most frequently asked questions, helping you to choose the enterprise-grade platform that will best support your digital transformation.

[ivory-search 404 "The search form 18418 does not exist"]

Architecture Components

These components are, generally, 3rd party servers and services the Aurachain Platforms uses. On-prem, these are servers deployed with the platform and on-cloud, we are using what AWS or Azure offers.

Aurachain architecture components are:

  • Transparent Load Balancer
  • NATS
  • Persistence
  • Storage
  • Logging & Analytics
  • Microservices

Transparent Load Balancer

This layer will route all incoming traffic to the Cloud Gateway instances. Depending on where it is deployed, it will use a cloud native solution like AWS ELB or a HA Proxy.


Aurachain Platform uses NATS for async communication where REST communication doesn’t make sense. NATS is an open-source message-oriented middleware. It allows the platform to obtain the best performance and scalability while keeping its resilience.


For performance and flexibility reasons Aurachain Platform uses both Relational and NoSQL databases.

Most microservices have a relational database. The business data, which is broken between application (process instance) data and Global Data Model data requires more flexibility, so it’s saved into NoSQL.


The Storage layer is used by both the platform and the Apps to store and deliver files. By default, it’s a simple File System that sits on top of a Ceph cluster or NFS Server. However, the Aurachain Platform can make use of the Simple Storage Service (S3) standard developed by Amazon and implemented by most cloud providers.

Logging & Analytics

This layer is meant to aggregate all logs, errors and performance metrics. It offers the needed transparency in a microservices architecture.

  • ELK Stack(Elasticsearch, Logsatsh & Kibana) is used for business data and logs:
  • Elasticsearch is a search engine based on the Lucene library. It provides a distributed, multitenant-capable full-text search engine with an HTTP web interface and schema-free JSON documents.
  • Logstash is a tool to collect, process, and forward events and log messages. Collection is accomplished via configurable input plugins including raw socket/packet communication, file tailing, and several message bus clients. Once an input plugin has collected data it can be processed by any number of filters which modify and annotate the event data. Finally, Logstash routes events to output plugins which can forward the events to a variety of external programs including Elasticsearch, local files and several message bus implementations.
  • Kibana is an open-source data visualization plugin for Elasticsearch. It provides visualization capabilities on top of the content indexed on an Elasticsearch cluster. Users can create bar, line and scatter plots, or pie charts and maps on top of large volumes of data.

Prometheus and Grafana are used for general server monitoring and performance metrics.


Microservices encapsulates all the business logic, communication, transformations, data processing, etc. All of this is done in a microservices pattern where services are stateless which allows them to be created/destroyed without side effects. Each handles a business domain only and (if needed) interacts with other services.


Written in Java with Spring Boot and Spring Cloud.


Single-page application pattern written in JavaScript, Vue.js, and Quasar.

Aurachain Platform uses the native Kubernetes Service Discovery as a service registry. All instances of backend microservices are registered as Kubernetes services and this allows for load balancing and failover.

In the following we will describe how what is the purpose of each service:

  • Frontend: This layer is a special case of a microservice. It contains all the required JavaScript and static files that make the Web UI SPA work but, by itself, it does not directly communicate with any other microservice. The client’s browser that runs the Web UI SPA communicates with the Gateway and, through it, with the other backend microservices.
  • Gateway: This layer serves as gateway to the cloud instance. It aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency. It is also where authentication is checked against the identity service and enriches the request with authorization details.

– Able to match routes on any request attribute.

– Predicates and filters are specific to routes.

– Circuit Breaking integration

– Discovery Client integration

– Easy to write Predicates and Filters

– Request Rate Limiting

– Path Rewriting

This allows us to have one tenant or multiple tenants inside a cloud instance. We can also have dev environments without having to spawn an entire cloud instance for special virtual groups. Our implementation uses Spring Cloud Gateway.

  • Identity: Stores data about the specific user so that the user can be identified, authenticated and authorized to access the underlying services of the platform. Manages tenants, groups, users and permissions. Can handle Active Directory/LDAP synchronization and supports SSO through SAML and 2FA for more security.
  • Design: It serves as a code repository during App development before the requested version goes into production by being published. It allows for rolling back of modifications and keeps tracks of everything that App designer do.
  • Engine: It is the core on the Aurachain Platform. It contains the process engine part and it also communicates with other services to manages the storage, versioning and execution of application development artefacts.
  • Data – Deprecated from 3.16: Manages the storage of Data model definitions and instance (business) data persistence. All this data is dynamic, so the App designers can easily change the structure and the content.
  • Document: Manages the document templates storage and document generation.
  • Notification: Handles user notifications – email and SMS. It has built-in auditing and retry mechanisms. For emails, it makes use of SMTP. The default SMS implementation is Twilio SMS but there are ways to implement any SMS provider.
  • Integration: Manages the storage of API definitions, API credentials and the exposing/consuming of API endpoints. It exposes user-defined SWAGGER services and can consume SWAGGER and SOAP definitions.
  • Real-time Notifications (Websocket): Manages the real time communication of client side (browser) notifications in pub/sub pattern.
  • GUI: Manages the storage of GUI templates, fragments and components.
  • Log: Allows business app owners to extract business-related technical log files from the system. Behind the scenes, it accesses the Elastic Search server to retrieve the data.