Three-tier architecture

Essentially, this is a three-tier architure with a separation between the frontend, backend and database
That's the foundation of this full-stack solution. This enables all the three aspects to evolve independently of each other, giving room for innovations and scalability.

Let's have an overview of the key features. Detailed information of each of these components comprising the architecture falls in either the Frontend Documentation or Backend Documentation

BFF (not "Best Friend Forever" but Backend For Frontend)

This pattern allows backend services to isolate clients based on their needs. One of the major necessity of Backend-For-Frontends (BFF) is to provide a single access point to the backend, reducing the surface area of entry.
A BFF takes care of security implementations for the frontend, such as obtaining tokens on behalf of the frontend client and managing sessions.
In this case, the bffweb service is dedicated to serving the web version of The Hub Ecommerce.
Ideally, if a mobile frontend is available (soon), we could have another BFF named bffmobile to serve the mobile app.

Service Bus: Gateway & Saga Patterns

The Aggregate Service acts as the enterprise service bus, managing all communications to and from within microservices themselves. It acts as a gateway for all communications. This service takes receives messages from microservices, queues them up in the messaging server (RabbitMQ) and acknowledges reception. This eliminates the need for microservices to manage communication with each other by only talking to the service bus and saying "I want this message delivered to X service".
For detailed information on this: see Backend Documentation

DBOP Service

We chose this clever design to take care of all database operations on behalf of all other microservices. This makes it easier to scale, and eliminates a plethora database connections that usually go out-of-hand.

Notification Service

The Hub Ecommerce was designed as a large-scale project in which messages (sms, emails, WhatsApp) would be constantly sent.
To guarantee deliverability of these messages, Notification service was designed to store, send and audit messages asynchronously. This is an inbound service whose sole purpose is to channel notifications. Let's say the

Callout Service

Considering the number of microservices, it makes sense to have a sigle service taking care of external service calls.
This service receives instructions from other microservices (consumes from the queue), decoding the destination (HTTP URL), method (GET, POST, PUT) and data (optional) to be sent to the third party service.
The service is clever enough to channel back the response from the third party (if it was required by the instucting microservice). This way, the architecture remains asynchronous and guarantees reliability.

That conludes the architecture that The Hub Ecommerce is developed on.