‫Welcome back to another practice lecture.
‫In this lecture, we will design another complex but real life system.
‫As always, we will follow a very methodical process that will take us from the initial vague and ambiguous
‫task to a detailed software architecture that satisfies all the functional and non functional requirements.
‫So let's start with the general description of our task.
‫Our current task is to architect a highly scalable eCommerce marketplace platform where different merchants
‫can upload and sell their products and users can browse, search and buy those products.
‫And just like before, we're targeting millions of users located in different countries around the globe.
‫Of course, at this stage this may seem a very big undertaking given that companies that run such systems
‫employ thousands of engineers and there are so many different components to such a system.
‫But we are software architects and there is nothing we can't solve if we follow our usual step by step
‫process.
‫So let's start with the first step, which is clarifying our functional requirements.
‫This will narrow our scope to what we need to care about, leaving everything else out of the picture.
‫We first need to notice that in this case we have two actors in our system, merchants and buyers.
‫So we need to clarify the functionality for both of them separately.
‫For example, let's start with some questions about the merchant experience.
‫Are we talking about digital products like ebooks or music or physical products with a fixed inventory?
‫What kind of information does a merchant need to provide us when they're onboarding a new product to
‫our system?
‫What kind of data should we provide the merchant with about their product sales, if any?
‫Or what kind of operations do we need to allow a merchant to perform on their existing products?
‫When it comes to the buyer's experience, we can ask the following questions.
‫Can anyone browse and purchase products on our platform or do they need to be registered users?
‫Do we need to design a product review and rating system?
‫What kind of product search capabilities, if at all, do we need to provide?
‫What parts of the checkout experience do we need to design?
‫And do we offer only a browser based UI or a mobile experience as well?
‫So let's assume that after clarifying those requirements, we have the following information.
‫First of all, the products were listing and selling our physical products with a limited inventory.
‫Each product has a title description list of categories and images, but it can also contain additional
‫attributes such as available sizes, colors, special features, and so on.
‫For the merchant experience, we have the following two requirements.
‫First, we need to provide the merchants with a product management system using this web based system.
‫They can sign up, create new products, update the properties of existing products, update the inventory
‫of an existing product, and also view their current product data.
‫The second functionality is analytics.
‫Using their merchant dashboard, they can view their current number of visitors to their products page
‫in real time, as well as seeing the historical and projected trends about their products performance.
‫When it comes to users or buyers, we also have two main functional requirements.
‫The first one is a storefront in this storefront.
‫A user of our web UI or mobile app can browse through existing products and also search for products
‫based on their title categories and description.
‫No user registration is necessary and product reviews are out of the scope for this design.
‫The second functionality is user checkout.
‫After a user adds items of existing products to their shopping cart, a user should be able to navigate
‫to the checkout page.
‫On that page, they will see the complete breakdown of how much they need to pay, including taxes.
‫Once the user fills in the shipping and payment information, they should be able to complete the purchase
‫with a click of a button.
‫When a user completes the purchase, they should receive email updates and mobile push notifications
‫about their order throughout the entire process.
‫The shopping cart is 100% on the client side and is stored on the user's app or browser.
‫And also we can offload the complexity of product delivery and payment to third party APIs.
‫Now we have a much better understanding of what is in scope and more importantly, what is out of scope.
‫But since we have two actors, multiple external service providers and so many different features,
‫it may still feel a bit overwhelming.
‫But that's okay.
‫For such occasions, we have a great visual tool that we can use to organize our requirements, and
‫that is a sequence diagram.
‫So let's start with putting all the actors in our system, the merchant, the user, and the third party
‫service providers, which are the payment and the delivery system.
‫So first, let's start with the first functional requirement for the merchant.
‫After the merchant signs up with our platform, they can log in and create a new product with an initial
‫inventory.
‫After the initial product upload, they can update their inventory at any time or update their product
‫details such as description, title, pricing, or any other data at any time.
‫For the second requirement, all we have to do is add the ability for a merchant to open their dashboard
‫and send a request for the analytics on their product.
‫Now let's jump to the first functional requirement for the store user, which is the storefront.
‫When a user comes in, they send a request for the available products in our store.
‫Of course, when implementing this API call we will use API pagination since loading all the products
‫in our store on the user's device would be unreasonable.
‫After that, the user can also make a product search to narrow down the list of products they're interested
‫in.
‫Obviously, the list of products returned by the query may also be very big, so we'll use API pagination
‫here as well.
‫And when a user clicks on a particular product, they should be presented with the full product page
‫where they can add that product to their shopping cart.
‫Now let's move to the user's second requirement, which is the user checkout.
‫Once a user is done adding products to their shopping cart, they send us a request containing a list
‫of products and their quantities.
‫A response from our system should contain a full breakdown of the final cost, including taxes.
‫After that, the user fills in their shipping and billing information on their browser or app.
‫And when they finally click on the purchase button, a request goes to our system with all the filled
‫in information internally.
‫We record the purchase, update the inventory, and send the purchase confirmation response to the user.
‫Then we build a user by calling the Payment System API and schedule the shipping by calling the Delivery
‫Systems API.
‫Also, at every transaction stage we will send an email and push notification to the user's device.
‫Finally, once the delivery system receives and makes any progress in the product shipping, they will
‫send us a message which will also result in an email notification to the user.
‫And that's it.
‫Now let's go ahead and proceed to the second part of gathering our systems requirements, which is clarifying
‫the quality attributes for each use case for the merchant experience.
‫Scalability is not a big issue.
‫We'll likely have only a few hundred of merchants at most.
‫And also those product or inventory updates will happen very rarely.
‫Also, the overall total number of products will have in our system will probably be in the thousands
‫or so.
‫In terms of performance, we should provide our merchants with a decent user experience, but they can
‫probably tolerate more latency than our end users.
‫So our response time of under one second at the 50th percentile should be good enough.
‫Regarding the storage we use for the products and inventory.
‫We definitely prefer consistency and partition tolerance over availability and partition tolerance,
‫since merchants always need to have the most correct data about their products.
‫Finally, we do want to provide merchants with high availability, but just like in the case of performance,
‫they can probably tolerate more downtime than end users.
‫So 99.5 of uptime or close to it should be good enough.
‫On the user side of things, we have a completely different picture.
‫Scalability is of utmost importance.
‫We plan to offer our products to tens of millions of customers in different countries, and when there
‫are flash sales or holidays, we should expect very high traffic to our storefront and checkout.
‫Also, performance has to be very high for the storefront.
‫We need to provide the users with a list of products and all the product details at less than 200 milliseconds
‫at the 50th percentile and under 500 milliseconds at the 99th percentile.
‫The performance of the checkout should also be very high, but probably not as high as for browsing.
‫So maybe keeping it under one second and the 99th percentile should be a reasonable.
‫When it comes to data consistency.
‫However, the store front and the checkout have completely opposite requirements for the storefront.
‫We prefer availability over consistency to show the users some data, even if it's not the most up to
‫date.
‫But when it comes to product inventory, we would rather give a user an error in case of a network partition
‫than build them for an item we no longer have in stock.
‫And finally, we want high availability for both scenarios on such a scale.
‫Every minute our store is done.
‫We may lose millions of dollars, but since we don't have any contract with our users, we don't have
‫to provide any external sales.
‫But internally, we should aim for four nine of availability at the very least.
‫So now that we captured all of our requirements and in particular the functional requirements, both
‫as a general list of features and the sequence diagram, we can proceed to the next step, which is
‫defining our API.
‫However, thanks to the clarity we got from the sequence diagram, this step will be pretty technical,
‫so we will skip it in the interest of time.
‫Instead, we will proceed to the next step, which is translating our functional requirements into an
‫architecture diagram.
‫However, before we do that, let's quickly recap what we've done so far.
‫We started with a very vague and ambiguous description of a system we need to design following our usual
‫methodical approach.
‫We started with clarifying questions to identify what requirements are in scope and more importantly,
‫what requirements are not in scope either because we just don't care about them or because we can delegate
‫them to third party services.
‫Later, we created detailed sequence diagrams for each merchant and user journey.
‫And finally, we captured a very detailed list of quality attributes that we need to strive for in our
‫final design.
‫I'll see you guys in the next lecture.