Service system design and delivery

Home and Search flow

 There is a provision for two user interfaces: a home screen with

personalised or general recommendations dependent on whether the user
is a returning or new user, and a search page where users can see results
based on some search text.

 A corporation with the scale of Amazon will now interact with a variety
of suppliers. To manage these providers, we'll require a number of
 services, which we'll refer to as Inbound Services. These inbound
services will communicate with supplier systems and retrieve pertinent
information. When a new supplier is added to the system, or when a
supplier adds a new item to their inventory, the information must flow
into the system such that it is easily accessible to the user. This
information will once again enter our system via an inbound service and
reach the user on the homepage or through search results via various
consumers listening to a Kafka that will receive events from inbound
services whenever such changes occur. Let's take a closer look at these
individuals.

 One of the system's customers is an Item service, which will listen to

Kafka for new items and expose APIs for adding, updating, and retrieving
them. Because the data connected to this item will be unstructured, it is
stored in a MongoDB database. Unstructured in the sense that distinct
items will have diverse characteristics. A shirt, for example, will contain
features such as size, fabric, and colour, but a television will have
attributes such as screen size, colour technology, weight, resolution, and
so on.

 A search consumer will ensure that a new item can be queried by users
as soon as it is on-boarded. It will read and process all new things being
onboarded, formatting them so that they can be saved in the database and
understood by the search system. After formatting, the data will be
stored in an ElasticSearch database by the search consumer. Elastic
Search is used here because it is incredibly efficient for text-based search
and also enables fuzzy search, which we want for a consistent user
experience. Certain we go over in greater detail in another session where
we look at which databases are best for which circumstances.
 Now, a Search Service that interacts with Elastic Search will expose
APIs for filtering, sorting, searching, and other operations on the
products. If you recall, we stated ‘search with delivery ETA' in the
functional requirements. This can be extended to the requirement that we
not show search results that cannot be supplied to the user because that
would be a bad user experience. The search service will communicate
with a Serviceability and TAT service to do this. The serviceability and
TAT service will determine which warehouse the goods will be shipped
from, as well as whether or not there is a route between the warehouse
and the user's pin code, and if so, whether or not that route can be used to
transport this product. It will also calculate an estimated delivery date and
pass this information on to the search engine. This information will be
communicated to the user by the search service.

 The user should be able to add a product to their wish list or basket from
the search screen. Wishlist Service and Cart Service are used to do this.
Wishlist service is a repository for all wish lists and cart service is a
repository for all carts in our system. Both of these services will be
constructed in the same way, with APIs for fetching, updating, adding to,
and deleting things from a Wishlist or cart, and they will both use
MySQL databases. They can be constructed on the same hardware, but
because wish lists are often very large, especially when a sale is
approaching, it is recommended that these services be developed on
separate hardware. Scaling the hardware for specific services becomes a
lot easier this way.

 Each time a search is performed, an event is sent to Kafka. This allows

Amazon to create a tailored recommendation system based on the user's
 preferences as well as a general recommendation based on the most
popular products. Similar events will be sent to Kafka by Wishlist and
Cart services. Let's take a closer look at how the analytics portion of the
system will function.

 The Kafka service will be connected to a spark streaming consumer,

which will create real-time statistics such as the most popular products in
the last hour or day, the most wish listed item, the most popular shipping
destinations, the most revenue-generating categories, and so on. All of
this Kafka data will be dumped onto a Hadoop cluster, where common
algorithms like ALS can be used to determine the next set of things a
customer would need to buy based on their previous purchases, and
tailored recommendations can be generated for them. It will also tell us
about the things that other users with similar interests have looked for,
wish listed, or purchased, which we may add to this user's suggestions.
Once we get these recommendations, a spark cluster will talk to a
recommendation service, which is a repository of all recommendations
in our system, whether they're general recommendations based on a user
id or recommendations based on a product category. Users will receive
generic recommendations on their homepage; however, recommendations
will be filtered away if they are browsing a specific category of products.

 The User Service is the next component. It has a repository of all users as
well as APIs for retrieving, updating, adding, and deleting users from our
system. It makes use of a MySQL database and a Redis cache. Let's say
our search service needs to communicate with the serviceability service
about a user's pin code. The user service will first check Redis, and if
Redis doesn't have the information, it will look up in the MySQL
 database, retrieve the user's information, store it in Redis for later use,
and return it to the search service.

Purchase and Checkout flow

 When a user requests an order, the request is routed through an Order

taking service, which is part of the wider order management system. A
MySQL database powers the order management system. They have
numerous tables, such as a customer table, an item table, an order table,
and so on, with a lot of transactions going on across them. Since Amazon
don't want two people to be able to order the final pair of AirPods in our
warehouse simply because our database couldn't keep up with the update
quickly enough. This necessitates the use of relational databases with
ACID features, such as MySQL.
 As soon as the order taking service is called, a record in Redis will be
created containing an order id, the date and time the order was
created, and the order expiry period. Along with these details, there will
be a status associated with that order id, which will initially be "created."
The following step is to contact the inventory service. Before the order
was created, for example, there were 5 sets of Sony 65" Smart TVs in
stock. The inventory count for the product will be reduced to 4 after the
order is placed, and the user will be forwarded to payments. But why do
we update the inventory before we finish the payment? What if we only
had one TV in stock and three individuals wanting to buy it instead of
five? If we cut the inventory count before proceeding to the payment
flow, two out of three buyers will notice that the item is already out of
stock, and their flow will be terminated before reaching the payment
page. This is simple to accomplish by retaining an inventory count
restriction so that if the count drops below zero, you won't be allowed to
place the order.

 Once the inventory has been successfully updated, the order taking
service will communicate with the payments service, which will
communicate with the payment gateway and complete the payment
flow. This payment flow can now have three different outcomes: success,
failure, or no response. Let's begin with the joyful flow. Let's say order
O1 was placed at 10:01 with a 10:05 expiry time, and we received a
payment success answer at 10:03. In this scenario, the order status will be
changed to "put," and an event will be triggered to Kafka indicating that
an order has been placed for this product with these specific order
parameters. What would have happened if the payment had been
unsuccessful? Remember that we changed the inventory before beginning
the payment flow. This indicates that the order has already been entered
 in the inventory system, and now since the payment has failed, we must
cancel the order. This signifies that the status of the order will be changed
to "cancelled." Amazon then communicates to the inventory service
again because the order has been cancelled, and we'll need to revert the
count in the inventory database. We will have a reconciliation mechanism
on top of this order taking and inventory system to guarantee that the
order count and inventory count are in sync and not inconsistent.

 In order to maintain consistency, the database require ACID qualities,

which was the whole idea of using MySQL in the first place. But Amazon
will need to maintain all of the orders in MySQL, even if they've been
delivered or cancelled? They've already reached the end of their life cycle
and will have no impact on other orders. So, when an order achieves a
terminal state, such as delivered or cancelled, it’ll be moved to
Cassandra, which will be done via the order processing service and
historical order service. These services are part of the bigger order
management system once again. The order processing service will handle
the order lifecycle, which means that any modifications to the order after
it is placed, such as retrieving order details for tracking or retrieving
orders by status, will be handled by this service. APIs for retrieving
details of delivered or cancelled orders will be available through the
historical order service. An archive service will query the order
processing service for any orders with terminal status, then communicate
with the historical service to insert them into Cassandra. Once this
Cassandra write is complete, the order processing service will
communicate with Cassandra to delete the finished orders from the
MySQL database.
Role of Technology

System architecture

 The massive technology core that keeps Amazon running is entirely

Linux-based. As of 2005, Amazon has the world's three largest Linux
databases, with a total capacity of 7.8 terabytes (TB), 18.5 TB and 24.7
TB respectively [ref]. The central Amazon data warehouse is made up of
28 Hewlett Packard servers, with four CPUs per node, running Oracle 9i
database software.
 The data warehouse is roughly divided into three functions: query,
historical data and ETL (extract, transform, and load -- a primary
database function that pulls data from one source and integrates it into
another). The query servers (24.7 TB capacity) contain 15 TB of raw data
in 2005; the click history servers (18.5 TB capacity) hold 14 TB of raw
data; and the ETL cluster (7.8 TB capacity) contains 5 TB of raw data.
Amazon's technology architecture handles millions of back-end
operations every day as well as queries from more than half a million
third-party sellers.
 Amazon employs the Netscape Secure Commerce Server using the SSL
(secure socket layer) protocol. It stores all credit card numbers in a
separate database that's not Internet-accessible, cutting off that possible
entry point for hackers. Customers who are particularly cautious can
 choose to enter only a partial credit card number over the Internet and
then provide the rest by phone once the online order is submitted.

Amazon App Suite

 Amazon app suite provides quick access to top Amazon apps all in one
place. With this widget on your screen, you can download or start
Amazon Underground, Apps & Games, Music, and Kindle from the same
convenient location

Amazon Warehouses Automation

 To improve its performance and costs, Amazon is investing heavily in the
mechanization of its warehouses. With conveyors or sorting platforms for
example, or by buying a company such as Kiva System, which creates
robots (now Amazon Robotics). Amazon had 47,000 robots in 2017
compared to 15,000 in 2015.

Amazon Drones
 A very good communication boost from Amazon because delivery by
drone remains impossible in urban areas for several obvious safety
reasons. Based on the Amazon principle, it claims to be able to deliver in
less than 30 minutes within a 16km radius of the delivery centre.
Nevertheless, Amazon is putting in place strong lobbying to achieve its
goals.

Amazon Flying Warehouse

  It is a somewhat surrealist patent for the moment filed by Amazon of an
airship that would act as a floating warehouse from which drones would
come to deliver you directly within a certain radius around the airship.
This clearly shows the Amazon Group’s extremely long-term vision to
always try to deliver its customers ever faster at the lowest cost.

Amazon Web Services

 Jeff Bezos quickly understood that the data, the famous Data, would be
essential for Amazon’s development in the 21st century.
 Amazon developed in-house technical solutions, which were then shared
with the public at unbeatable prices. The revenues from this have
obviously been reinvested to reduce costs and develop new and in terms
of Supply Chain, all the information collected by Amazon is then
collected and consolidated in a huge database to optimize all its logistics,
transport, supply chain and costs.
 As a result, Amazon now offers a considerable number of services in
computation, machine learning, security, IoT (connected objects) and
analytics. I come back in particular to Machine Learning where Amazon
has truly become a reference today. With Amazon Machine Learning, it
is now possible to create a large number of applications with very
different objectives thanks to Amazon’s algorithms and the data you have
saved.

Amazon Machine Learning

  In Supply Chain, machine learning allows you to better organize your
forecasts, calculations, costs and flows. The only condition to use this
service is to have your own data, provided that it is well structured,
registered in the Amazon service and that the objective of Amazon is to
repatriate as many companies as possible as well as their data. and then
offer more services.

Management of supply and demand

 Amazon has made a recent shift in how they are communicating
inventory demand to vendors with the addition of a new feature:
Probability Level Demand Forecast (available in both ARA Basic &
Premium).
 Vendors are now being forced to make some critical decisions that will
directly impact their stock levels for Amazon (and potentially impact the
success of their entire business) although demand will continue to be
based on glance views, sales history, and projected demand for planned
promotions
 Amazon Retail Analytics (ARA) is one of the most powerful tools
available to vendors who want to better understand and improve their
operational performance.
o Amazon currently offers two versions of their ARA program via
Vendor Central including Basic & Premium:
o ARA Basic is a program automatically provided by Amazon to
vendors. Recently, there’s been several enhancements to ARA
 Basic which allow vendors who choose not to have ARA Premium
to get more specific data than in the past.
o ARA Premium is an advanced version of the Basic program. For
an additional fee, vendors can apply for access to this add-on suite
of additional reports.
 Vendors are now being forced to make some critical decisions that will
directly impact their stock levels for Amazon (and potentially impact the
success of their entire business).

 Although Demand will continue to be based on glance views, sales

history, and projected demand for planned promotions, the forecast will
now have three new probability forecasts for the vendor to choose from
including:

o P70 – Means there is a 70% chance Amazon will purchase the

level of demand indicated or less and a 30% chance they will
purchase more.

o P80 – Means there is an 80% chance Amazon will purchase the

level of demand indicated or less and a 20% chance they will
purchase more.
o P90 – Means there is a 90% chance Amazon will purchase the
level of demand indicated or less and a 10% change they will
purchase more.
 Amazon prefers vendors use the P90 forecast (as it makes inventory more
readily available).
 However, the risk tolerance for doing so is solely on the vendor. Even if
Amazon issues a demand forecast, it is not a promise of purchase orders.

 Simply put – even though Amazon shows demand in your product(s),

purchase orders are not necessarily guaranteed.

 There are several key factors that can influence whether Amazon decides
to issue POs from a vendor including:

o Availability from other suppliers at a better price

o Vendor lead-time
o Profitability of the ASIN
 In addition to the new P-level forecasting feature, Amazon is also adding
a new “Mean Forecast” and discontinuing their projected safety stock.

o Introducing Mean Forecast:

 This new forecast is used for vendors that need more lead-
time to acquire inventory (6 weeks or longer).

 This will be a key component for vendors who manufacturer

overseas with longer lead-times.

o The End of Projected Safety Stock:

 The other key change is Amazon is no longer projecting a
safety stock above demand.

 In the past they have used the Vendor Lead-Time (VLT)

plus 7 days (in most cases) to project what needs to be
 purchased. They will now only use the VLT for the
calculation for purchase order issuance.

Vendors can implement to better manage their product demand

relationship with Amazon:

 Review Demand – The demand forecast is forwarded looking for 26

weeks and for the most part only considers what the potential need will
be. However, it does show the demand for the previous 13 weeks prior to
the current week. The vendor can review this demand and compare it to
the purchase orders issued to see what level of ordering Amazon has
come closest.

 Begin Tracking Demand vs Purchase – Vendor can also begin tracking

the demand vs. purchase orders on a weekly basis to verify what level
Amazon is purchasing. It is suggested this data be looked at over a two to
three-month window for accuracy.

 Prioritize Your Top ASINs – Even though the vendor is seeing only the
forecast they pick on the screen, when downloaded they will see all
forecasts. Not all ASINs will need to be stocked at the same level. It is
suggested they make sure they are covered on top ASINs at the highest
levels possible and adjust accordingly to lesser important ones.

 Avoid Chargebacks – Amazon is still expecting a 100% confirmation

rate as well on-time shipping accuracy. Under purchasing to demand
could potentially impact both areas and create chargebacks if not handled
correctly.
  Communicate with Amazon – Depending on the volume the vendor
does with Amazon it is suggested that if they have regular contact with
their Vendor and In-Stock Managers, they communicate with them to get
even more understanding of how to use the forecasting models.

Quality Management at Amazon

“We see our customers as invited guests to a party, and we are the hosts. It’s
our job every day to make every important aspect of the customer experience a
little bit better.”
Jeff Bezos, Founder & former CEO of Amazon

 According to Bezos, the key to the company’s success has been truly
listening to their customers and continuously pushing the boundaries to
provide them with what they are looking for.

 All Amazon sellers are responsible for complying with the law along with
Amazon’s policies. Customers trust that they can buy with confidence on
Amazon and receive authentic products that arrive in the condition
advertised. In order to ensure that both sellers and customers have the
 best experience, below are some tips that sellers might find helpful when
listing products on Amazon.

 Seller Quality Management System (QMS)

o The seller will maintain an internal QMS that enables the timely
identification and reduction of product quality and operational
defects. While certification is currently not required, adherence to
the ISO 9001 policies and guidelines is highly encouraged.

 Performance Monitoring

o To help ensure compliance with the Amazon Renewed Global

Quality Requirements, sellers must meet the following
performance metrics:
 Perfect Order Percentage > 85%
 Order Defect Rate < 0.8%
 Renewed Seller % of Negative Reviews (1- and 2-star
reviews) < 10% (as a percentage of all reviews)
 Renewed Quality Score (RQS) > 98% (seller level). Details
on guidelines, expectations and enforcement mechanisms
can be found on Seller Central. Once approved to sell on
Amazon Renewed, you can access your RQS report here.
 Seller's overall Average Product Rating (APR) should be
> 4.0

o Products will be subject to random test buys that serves as another

mechanism to ensure compliance with these requirements. Amazon
 Renewed reserves the right to conduct test buys at its own
discretion. Products purchased for this purpose will be returned to
the seller as per the regular returns process and will not affect any
performance metrics.

o Failure to comply with the Quality Requirements might lead to the

removal of selling privileges on Amazon Renewed, and might
require the submission of a ‘Plan of Action’ to remediate and
regain said privileges.

o At any given point and at its sole discretion, Amazon Renewed

reserves the right to remove any selling privileges if it is believed
that an optimal customer experience is compromised.

Comparison: Amazon vs Flipkart

Parameters Amazon Flipkart
Company Type Public listed Private listed
Total Assets US $37.6 billion US $1620.58 billion
Presence Global Partnership based(eBay)
Core System Linux PHP, JAVA
Architecture
Technology Data Science-Ml/AI Data Science-Ml/AI
Mobile application Mobile application
Robotics and Automation Robotics and Automation
Drones
Flying warehouse

Delivery Amazon prime Flipkart +

3PL 3PL
Last Mile Delivery Last mile delivery
Drone delivery
 Air delivery
Quality ISO 9001 certified Seller 6 stage insta quality
Quality Management check under Flipkart
Services Assured