This reference architecture mainly serves to demonstrate the distributed architecture of the application as multiple microservices and conversely, the composition of three microservices along with a presentation aggregation layer to form a functioning application.

The layers of this reference architecture roughly follow the one depicted in the diagram for Business-Driven Microservices.

The client, typically a web browser, makes calls to the load balancer layer. The load balancer is an Apache HTTP Server web server using mod_proxy to balance incoming requests between the three nodes of the next layer. Load balancing uses a simple round-robin algorithm with sticky behavior, ensuring that barring a server failure, a given user always reaches the same server node.

The second layer serves as both the aggregation and presentation layer and is the client to the microservices layer shown in the referenced architecture diagram. It is implemented as three separate logical machines, each hosting their own EAP instance and deploying the presentation.war application. With customer’s shopping carts being persistent, the only in-memory state held by this application is the logged in user’s identity. While in-memory state replication is offered by the EAP servers, the low impact of failure makes it optional. At worst and in the event of a server failure, the users with active sessions on that server will have to log in again to continue where they left off. This aggregation layer, mainly implemented in the RestClient class, makes its calls to the three microservices through the load balancer in the first layer.

The microservices layer consists of three sets of three logical machines, with each set hosting one of the microservices. These microservices are completely stateless and use simple load balancing by mod_proxy without any sticky session behavior.

The database layer consists of two logical database servers, one for the product and anther for the sales microservice. In terms of the physical deployment, these two databases are implemented as two schemas of the same MariaDB server, hosted on the same physical machine as the Apache HTTP Server.