OneShop e-commerce architecture and its components

We started the OneShop journey in November 2018 from scratch and so far its architecture has evolved. It is an ecosystem that is futuristic, cloud-native, and scalable. This is article is an overview of Oneshop, best in class digital commerce solution.

OneShop identified the underlying business problem to unify all the NatCos & build a digital sales platform. These business goals motivated us to build a new platform from scratch using modern technologies with the following high-level objectives:

creating a multitenant architecture.

reusable service for all digital channels.

using open source tools and technologies.

Before we start few terms to understand:

1. Natcos: National companies of DT in various European countries.
2. HAL APIs(Harmonized API Layer). A logical layer of API specifications implemented by Natcos over telco BSS and OSS stack.
3. Channel: An application layer consisting of a user-client(App or Web) and
4. BFF (Backed for frontend).
5. DPS (Digital Platform Service): A microservice meant to serve a particular domain. This exposes services that are channel-agnostic and multitenant to serve all natcos from a single codebase and deployment.

Three Tier Architecture:

Tier-1 and Tier-2 have born in AWS-cloud whereas Tier-3 exists in DT’s local cloud.

Every service is multitenant. Multitenancy has been implemented with a beautful abstraction provided by MultiTenantResolver.

Every REST API call is done using MultitenantFeignClient.

MySQL database interaction is done through MultitenantDataSourceTransactionManager and MultitenantJdbcTemplate.

Mongo DB interaction is done through MultitenantMongoTemplate.

Let’s navigate from bottom to top:

1. HAL API Layer (Tier-3): This layer exposes APIs from the telco stack that exists in natcos. They follow common HAL API specifications. Services from tier-1 and tier-2 connect to the HAL API layer through public internet with two-factor security: IP-whitelisting and JWT-Assertion.
2. E-commerce stack (Tier-2): This layer consists of dedicated e-Commerce services and supporting services.

• Sales Catalog: A typical catalog containing product definitions. It is composed of catalog admin UI, and an API exposing layer. It provides product listing, product filtering, and product details capability. In order to achieve high scalability, it stores data in Mongo and Elastic search. It offers on-the-go dynamic filter creation and usage.
• Sales Inventory: Every product in e-Commerce has some stock count associated with it. Based on the available stock a product status can be IN STOCK or OUT OF STOCK. Inventory is stored in the Mongo database. In order to sync the product status, it uses mongo change stream event listener event to run status sync conductor workflow for a product.
• Distributor: This is a bridge to load data into sales catalog and sales inventory from the local product catalog and product pool which is at natcos end. Upon receiving an API trigger from natcos, it runs a sequence of conductor workflows for data sync.
• Shopping Cart: This a typical shopping cart of e-commerce. It is used to store items selected by the customer during the shopping journey. It maintains the complete lifecycle of the user’s shopping cart. Shopping carts of the users are stored in AWS-RDS database.
• Order Tracker: The orders submitted by customers after the checkout journey are stored in the order tracker. Order states are updated in order tracker by the order fulfillment manager (running at natcos end). All historical orders of the customer are viewed from the order tracker. The orders are stored in the Mongo database.
• Supporting services: Apart from DPS(s) there are many other supporting services that power e-commerce platform. These are covered in the subsequent section.
• Multitenancy View of microservice:

3. Channels (Tier-1): These are the customer-facing application layer. Every channel consist of a user-client app and a dedicated backend for the frontend (BFF). Tier-2 powers e-commerce capabilities to channels like Oneshop and Oneapp.

• Oneshop: This is a web-based channel meant for providing an e-commerce experience to our potential customers in the market. Web front is a ReactJS application running on a node server. BFF is a spring boot application that uses REDIS for performance boosting.
• OneApp: This is a self-care mobile app (IOS and android) meant to fulfill the service needs of our existing customers. It also has its own BFF to fulfil the presentation and data needs of the app.
• BFF does not have any databases connected to it.

Supporting Services/Components:

All services or component defined in the subsequent section are reusable across channels and platforms.

1. CMS: Content Management System is used to manage feature enable/disable configurations, multilingual translations.
2. Page Builder: This an admin application that can be used to create custom homepages, microsite pages, embedded pages, etc. The authentication is powered through keycloak SSO.
3. Zuul Gateway: This is an entry point to access any service of the e-Commerce stack. It contains a specialized filter to do authentication through keycloak for any request coming from an external client (from outside AWS).
4. MultiTenantResolver: This an abstract interface used to resolve applicable countries in all situations like making HTTP calls, interacting with DB, performing authentication through SSO, etc

public interface MultiTenantResolver {
    String getTenant();
    String getTenantWithFailSafety();
}

5. MultitenantFeignClient: This is a multitenancy-aware implementation REST client developed on the top of spring cloud open feign. In addition, this client also provides the ability for comprehensive management for parameters like connection timeout, read timeout, and URL for each tenant(where each tenant is a country).

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Documented
@FeignClient
public @interface MultitenantFeignClient {
}

Sample configuration of multitenant :

feign:
  client:
    config:
  loginClient:
          tenant:
            pl:
              url: "${pl-base-url}/onboarding/v2"
            cz:
              url: "${cz-base-url}/onboarding/v3
......
......

6. Metric Recorder: Each microservice records micrometer Timer metrics. Metric is recorded with reference to a traceable metric name across various services like ADD_TO_CART, DEVICE_LISTING, etc. This helps us in creating a collective performance view of a business operation.

Common Traits In-Services.

• Most of the microservices are spring boot-based.
• Services are deployed in the Kubernetes container.
• They read configurations from spring cloud config server.
• Services can be managed through Spring Boot Admin.
• They share a common entry point via zuul gateway.
• Every connection with a microservice or HAL API is done through hystrix circuit breaker.
• They share a common logging framework that sink logs in ELK
• All services generate Prometheus metrics accessible through /actuator/Prometheus.

This is all about OneShop architecture in a nutshell. Stay tuned to follow detailed articles for each service!