Cloud Computing Project

This documentation describes a microservice architecture for JPetStore project and plans to implement it in a cloud environment.

Overview

JPetStore is a simple pet store web application written in Java using Spring. A sample demo of the original monolith application is available here.

The application has a hierarchical catalogue, a user registration and authentication system, and a purchase system with a shopping cart. In compliance with this, the monolith has three separate services:

• Catalog: provides a catalogue of products in hierarchical categorisation.
• Account: provides user authentication system using token-based authentication.
• Order: handles the purchase process and shopping carts.

The original database structure has some flaws and redundancies which are addressed and fixed in the proposed architecture.

In the following sections, a three-part architecture is proposed that will divide the monolith into the three aforementioned services, each with their own database and gRPC service. The architecture, if approved, will then be implemented from scratch using Node.js and MongoDB in phase 2.

Proposed Design

Microservices

The three microservices that best divide the monolith are the ones described above (auth, catalogue, and order), as they are already somewhat well-defined. Other reasons for splitting the monolith into these three services are:

1. The user authentication system only interacts with the rest of the application through the order mechanism.
2. The catalogue is mostly static and is updated either by admin to update or add new products or through the order system to update the stock.
3. The order system is the most dynamic and is updated frequently through purchases and cart management.
4. Each of these microservices has a clearly defined database structure that only interacts with the other two through gRPC.

Database Structure

The database, from the prespective of each service has the following models:

• Auth:
  • users: user accounts and information
  • resources: resource access control
• Order:
  • carts: shopping cart details, user_id, items, total, status, etc.
  • orders: order details (i.e. finalized carts with purchase information)
• Catalog:
  • categories: categories and subcategories, include parent_id for hierarchy
  • products: product details, category_id, stock, price, etc.
  • suppliers: supplier information, name, address, etc.
  • favourite categories: each user's favourite categories

Access diagram 1

Actors

The actors in the scenario are the following:

• Customer: the user of the application, can register, login, view catalogue, and place orders (create carts and confirm orders). It can also pick a favourite category to display in profile.
• Admin: the administrator of the application, can add, update, delete products and categories, manage users, and view orders.

Access diagram 2

Internal Communication

The specific internal communications are as follows:

• auth — order: validating auth token
• order — catalog: getting product information
• catalog — order: updating product stock
• for each operation, the services also verify the JWT token and access control levels through a gRPC call to the auth service. This means there are auth — order and auth — catalog calls.

Authors

Tooraj Taraz (Team Lead) user - auth	Hamed Ghoochanian catalogue - order	Afarin Zamanian design & doc