Architecture

JChem Microservices is implemented based on different Spring projects (Spring Boot, Spring Framework, Spring Cloud /AWS, Netflix, Config/, Spring Security ) . Many technical features of JChem Microservices are determined by the underlying Spring projects.
The services communicate via http as provided by Netflix Eureka Service.

Why does JChem Microservices have so many modules?

The idea behind JChem Microservices is to provide a solution with High-Availability, Robust and modern Web Service where highly used parts can be scaled up and rarely used parts can be switched down. For this we provide the opportunity to set up different parts of the software on many machines. All the services can be configured by a central Config Service, they all register into a Discovery Service and have a common entry point, which should be the only visible service in your network.
In this architecture, Config and Discovery Service should be single instances, the other parts can be duplicated if necessary.

It is also possible to run one or more modules in standalone mode, without the Config, Discovery and Gateway Services.

Architecture in system mode

Architecture in standalone mode

High Availability

The Spring elements make JChem Microservices highly available. Running more instances through the load balancer are the key tools for constructing a highly available system.
See the above architecture diagram as an example.

Autoscaling

Each chemical service of JChem Microservices can be scaled by running multiple instances through a load balancer. However, special care must be taken in case of the stateful services, please read the relevant sections of their documentation:

• Database Search Service
• Task Manager Service

Autoscaling capability of a system depends on how the given system was constructed. Here you find a load balanced example application on GitHub.