Microservices Architecture – CASE STUDY: Rainyday Grocer

 

This case study is a fictional MSA-based solution deployed in the cloud.

Introduction

Rainyday Grocer is a cloud-based online grocer that provides customized delivery of groceries. Their business model is targeted towards those “rainy day” moments where a person needs groceries but is unable to go the bricks-and-mortar grocery store to shop.

Business Scenario

Rainyday Grocer (RG) supports three different ordering options. A customer can:

  1. Place an order with one of the approved grocery stores, send the item list, and order confirmation to RG via a web interface or a mobile application.
  2. Send a grocery list to RG via a web interface or a mobile application.
  3. Select from RG grocery items list and place an order.

There are two delivery options:

  1. Doorstep delivery with text message confirming delivery.
  2. Collect groceries order from one of the RG collection points.

RG does not own any inventory, supply channels, distribution channels, or data centers. They leverage other service providers for all services, and manage quality through a careful selection process and SLAs. They maintain a lean team of 50 people, only 5 of whom are IT-focused, to manage their operations across five states in the Eastern US.

The customer has to accept a set of constraints to place a successful order:

  • The customer must have an active account in good standing (less than five floods; i.e., negative points).
  • The customer must have a valid payment method registered.
  • An order is limited to 10 or less items with a cumulative weight not more than 25lb.
  • RG does not guarantee any specific brands.
  • There is a four-hour window from order confirmation to requested delivery.
  • An order cannot include medicines or hazardous materials.
  • The delivery address must be a physical address.
  • The delivery address must be within 50 miles of a city center.
  • The customer must provide feedback within 24 hours, else get a flood.

MSA-Based Solution

RG is building an MSA-based solution.

The recommended approach for an MSA-based solution is to drive it from the business needs and address the business processes.

This case study examines the MSA solution for the receive order sub-process of RG. The focus is on building blocks and to highlight the MSA characteristics and principles.

The RG business process is shown in Figure 4, in Business Process Modeling Notation (BPMN).

Order-Delivery Process

The receive order business process is decomposed as shown in Figure 5.

Receive Order Sub-Process Decomposed

The above business process shows the more granular activities. The ones circled in red represent Atomic Business Activities for RG.

Adhering to the single responsibility principle of MSA, RG wants each of the atomic business activities to be fulfilled by an independentand self-contained microservice.

As RG is a lean organization consisting of only five IT team members they realize they will need to outsource this development work.

Taking advantage of the decentralized governance and polyglot development model of MSA, RG identifies business owners for each of the business processes and with responsibility to create autonomous teams to address the needs of that business process. But to avoid total anarchy, they also institute a lean enterprise governance framework as depicted in Figure 6 and Figure 7.

MSA Governance Framework at RG

MSA Governance

Consistent with the MSA principles, there is single team ownership of each microservice. (One team can own multiple microservices, but vice versa is not permitted.) Each team is autonomous – i.e., self-governs the entire lifecycle of each of its microservices – and is headed by the business activity owner. The business owner and the architects have a seat on the enterprise governance board, which ensures the enterprise governance model is correctly leveraged by each of the microservices teams.

The scope of the enterprise governance is kept minimal and non-intrusive to allow the autonomy of each of the microservices teams.

RG has standardized on an MSA Reference Architecture and a framework that each of the microservices teams will leverage.

Microservices Reference Architecture at RG

Leveraging the above reference architecture, each of the teams will develop, deploy, and manage its respective microservices.

Here are some of the microservices that are implemented at RG. Consistent with the characteristics of MSA, each of these microservices performs a single business activity and does it well, each is independent, stateless, and spawned as multiple parallel instances to ensure high resiliency.

All of these microservices are choreographed by the application or triggered by the generated events.

Account Login Microservice

This microservice allows the user to log in. It validates the user’s identification and security credentials, and ensures the account is valid based on a set of business rules.

The microservice API accepts an encrypted data object consisting of user credentials and account information. It queries the enterprise Identity and Access Management (IAM) solutions to validate the user credentials. It retrieves the user authentication token and account identifier.

Using the account identifier it retrieves the account history from the cloud-based CRM solution provider.

The rules are persisted in the in-memory storage of the microservice. It applies these rules to determine the account standing. If all validations pass, the service generates three tokens:

  1. User token that has a Time To Live (TTL) of the receive order transaction
  2. Transaction token that expires once the entire order delivery transaction is complete
  3. Service token that is leveraged by the MSA framework to monitor and audit the transaction. On completion the service also generates a login success or failure event.

This service is leveraged by other business activity owners for their respective business processes.

Receive Order Microservice

This service is primarily focused on receiving and processing the order. It is triggered by the successful login event, and waits for the order list data object from the customer.

Upon receiving the order list data object, it parses, categorizes, and validates all the items on the list based on the business rules.

It tags this order with the user token and transaction token generated by the previous services and generates the following:

  1. Order success (or failure) event
  2. Service token that is leveraged by the MSA framework to monitor and audit the transaction
  3. Data object that includes the items list and other procurement/processing instructions
  4. Propagates the user token and transaction token

Provide Estimate Microservice

The RG business model is a no-inventory model, hence the price of goods is dependent on the current market price for those goods. Therefore, RG provides an estimate range. This service periodically queries RG’s registered grocers for the current price list. It caches this information and is able to build and provide the estimate of prices for the item list published by the receive order microservice.

This microservice tags the estimates with the user token and transaction token generated by the previous services and generates the following:

  1. Estimate available event
  2. Service token that is leveraged by the MSA framework to monitor and audit the transaction
  3. Data object that includes the prices for the items list with additional metadata
  4. Propagates the user token and transaction token

Confirm Order Microservice

This microservice completes the order process and triggers the supply chain procure grocery sub-process. It sends a confirmation to the customer of order completion, with a confirmation ID and instruction on delivery collection of the order.

It tags the order complete event with the user token and transaction token generated by the previous services and generates the following:

  1. Order complete event
  2. Service token that is leveraged by the MSA framework to monitor and audit the transaction
  3. Data object that includes the final items list with additional metadata
  4. Propagates the user token and transaction token

Results

RG’s choice of MSA is well suited to their needs for the following reasons:

  • It allows them to implement a complex process with a very lean team.
  • They are able to quickly build teams with readily available skill sets to build each microservice.
  • They can make changes on-the-go; i.e., CI and CD and DevOps enablement.
  • Agility and flexibility.
  • Minimal CapEx and optimal OpEx.

Conclusion

This is a fictional case study that is deliberately exaggerated to highlight the core and auxiliary principles of MSA that are developed. The intent of this case study is to develop examples to add to the understanding of the microservices concepts and principles.