ECom Express Case Study — Software Architecture

# Key Requirements — Functional and Non-Functional requirements

●Office Staff should be able assign the packages to various delivery associates (functional)

●Admin has to verify the cash collection details from each delivery associate (functional)

●Server should be available to the mobile application which delivery associates use (non functional)

●User friendly UI, Easy to use for the delivery associate mobile app (non functional)

●Solution should be secure and the packages should be delivered to the respective address correctly (non functional)

●Notification of the status and delivery information should be available to both the end user and the delivery associate in real time with accuracy. (non functional)

●The payment has to be recorded according to the payment mode while delivery (functional)

●Identify of the right customer using digital signature or digital ID proof (functional)

# Three ASRs- Architecturally Significant Requirements

1.Mobile connectivity to the Server for real-time updates with delivery associates

Many mobile devices will be connecting to the server simultaneously and thus it can be loaded heavily and that can be a problem to be available all time. The system should adopt tactics to solve such high load conditions.

2.Related data for end-to-end delivery is easily accessible

The invoice and billing, shipping address and other digital proofs should be easily accessible and managed. The proof of reception of the packages so that the digital signature (physical signature on a device) will require advanced devices with touch screen to write the signature on it.

3.To streamline the Cash on Delivery money influx

System should be able to accurately quantify the cash collected but yet to be deposited by each delivery associate at a given time

#Utility Tree with Three ASRs-

# Tactics to address each ASRs-

1.Real-time availability of the System

The internet can be unstable and thus system should able to capture the details offline and push to server when available, similarly the relevant data already pulled from server can be cached to make sure it is available on the device all the time.

2.Correctness of information

Digital signature and Digital proof (latitude and longitude) of device can be capture to ensure the packages are delivered to correct person and at correct location.

3.Easy to use UI

Feature to call a customer without fetching the contact details and vice-versa. Option to record a cash payment after each Cash on delivery

# Diagrams

# Responsibility of 5 important modules

●Delivery Status Notification

Push notification for real-time updates on each step of the delivery from the package is picked up from the facility to the delivery has been completed.

●Navigation and Routing

Delivery associate should be able to navigate correctly to reach the delivery destination.

●Delivery Information Module

Data related to the delivery should be easily accessible. It includes invoice, payment mode, shipping and billing address and seller details.

●Cash Computing Module

This module streamlines the Cash on Delivery money influx. System should be able to accurately quantify the cash collected but yet to be deposited by each delivery associate at a given time

●Delivery Report

This module envelops the complete end-to-end delivery cycle. It covers all the status notifications generated, billing and invoice along with the shipping and billing details

# Key Scenario and module invoked sequence-

# Major Architecture Pattern —

●Microservices Architecture pattern used for the mobile backend server.

●Sathi application has various services hosted such as, google map connector, Delivery Update, Delivery Status, Payment Update

●Services are configured in such a way they are discovered at mobile backend server

●API Gateway, which will be working as a reverse proxy to all these services to constitute microservice pattern.

# Key Learning —

●It was challenging to break down the whole process of logistical system into modular form. The sense of service discovery amongst each inter connected modules were complex.

●The case study laid emphasis on understanding the need of each stakeholder. The sense of application is different for a delivery associate and a customer. This helped in finalizing the ASR.

●The Use-Case showing module interaction helped us to break down the chain from order to delivery. We were able to group multiple scenarios as part of same cycle. It helped us to visualize the architecture better.