Case Studies

Table of Contents


CASE STUDY A - RETAILER

I often find that complex ideas are best understood by describing them with a scenario. In this case, I’m going to use a fictional retailer - Mass Synergy - to help to crystallise some software concepts. We’ll use this case study as a reference point throughout the rest of the book.

Mass Synergy sells a range of products, from physical units that are posted out to their customers, to digital-only content delivered directly to the customer’s email account, to streamed Pay-Per View (PPV) events (e.g. golf). They also see possibilities to sell their services as a SAAS product to other (smaller) retailers (who don’t want to manage their own platform), and earn a commission from them. The diagram below shows the main components of their solution.

Customers use the retailer’s web-based user interface (UI) to shop for items, performing operations like: searching and viewing a catalogue, receiving discounts, and cart actions (add, remove, checkout). Under the hood, the website UI integrates with numerous independent Microservices through a Gateway. Each microservice represents a specific domain concept (e.g. catalog, carts, fulfilment).

Note that whilst there are many components to this solution, the business places greater import on some over others (I’ve marked these components with a red flag). For instance, customers are expected to be able to access their catalog, and store them in a cart, regardless of if other parts of the system (e.g. Fulfilment) are failing.

We have three classes of components that make up the application:

We'll use the following stakeholders to describe the Mass Synergy story:

CUSTOMER PURCHASE FLOW

The customer purchase flow is critical to Mass Synergy, consisting of six key stages. The flow is shown below.


I’ve marked each stage with a green circle to indicate the number of times that stage can be called (1 is once; N is multiple times). The flow is:

  1. Customer registers for the service.
  2. Create a cart - this is handled by the underlying system, and is transparent to users.
  3. View catalog - the customer views the catalog for products to purchase.
  4. Adds/removes items to cart - the customer manages the products in their cart.
  5. View cart - the customer verifies the items in their cart, prior to the final purchase.
  6. Checkout cart - the final stage also takes a payment and fulfils the request.

The team has confirmed the following SLA for it:

This equates to response times for 99% of the users, up to 100,000 concurrent users within the system, of less than, or equal to 2 seconds.

A (very basic) reference checkout pipeline is provided below.


FURTHER CONSIDERATIONS