Case study: Building scalable Notify Me service

Prerequisite: Amazon Simple Queue Service and Notify Me service. Please do read our post on the same: What is Ecommerce Notify Me service

A customer comes to your website to buy an item and it is out of stock. Notify me service  provides  a way to notify him when the item comes to inventory. Lets jump into the design part.

Components of Notify Me service

1. Java script component, or web components where customer inputs his email id.
2. Notify Me service ( probably SOAP service)
3. Client code to call this Notify Me service

The operations of  Notify Me service

1. Write operation: When customer fills his email id to notify the product arrival, the service needs to save <product-id, customer email id>  details.
2. Notify operation:  When out of stock product is received at the inventory,  the service needs to notify all the customers who are waiting on that.

Please see inventory service is the one which  triggers the notify operation.  We will discuss about the inventory service in the later posts.

Design

The notify operation design is simple, given product id it will pull all the customer email ids and send email to all those customers, one by one. The email have all the product description and product link. The hard part is writing the customer details  <product-id, email-id>

The Bad Design:

"The customer enters his details and submit and the service will save <product-id, email-id> in the db.
The first and trivial question is why it is bad?

• Well, you can ask customer to wait for a operation while browsing your website is only, and only if it is mandatory to save the data in the db so that he can reuse it immediately. Example: saving customer address - you have to say - wait till I save your address details in db, because these are going to be needed in the shipping. But in Notify Me service case, it is absolutely not required at this moment.  It may take a day, a week or a month to notify the customer.
• If the db is down at that moment you will loose all those  customer details. 
• It is burden/adds delay to trigger other services or populate other field.

The Good Design

• Send customer details to <product-id, email-id>  Amazon SQS -  a Simple Queue Service and acknowledge the customer that it is done - (or close the window)
• Write a program which reads from SQS and write into the db. 

Why?

• As SQS very reliable and it is very fast to send your details to SQS.  Basically you get the redundancy of 24 *7 service. 
• Even if your db is down, you can take your time fix it, later you can remove the object from queue and add the data to db.
•  You can add other columns by calling other services. Like - category, sub-category, date. 

Procurement Service triggering   

Trigger procurement service with the given product id to procure the product

Analytics Setup

One thing to consider,  please do add time stamp - date column  - <product-id, email-id, date>, because you are going to need them when you wants to take analytics out of it.

• Set up a ETL which pulls the data from Notify database - we don't need to pull email ids.
• Calculate product drops, number of "notify me" per product id. This values are going to be good input to  demand forecast. 
• The values should be per week or per month, depending on your forecast requirements. 
• Example: Number of times a particular book was requested to be notify, in a week or month.