‫Welcome back.
‫In the last lecture, we completed the functional design for our eCommerce marketplace platform.
‫We finished with a detailed architecture diagram that provides all the features we committed to.
‫And already some quality attributes.
‫However, we still need to make a few improvements to set our system for success.
‫So in this lecture, we'll address all the nonfunctional requirements we haven't yet addressed and update
‫the architecture diagram accordingly.
‫Let's start with the easier one, which is addressing the nonfunctional requirements of the merchants.
‫As a reminder, we have a few hundreds of merchants making infrequent updates and requiring a reasonably
‫good performance.
‫We also need to guarantee consistency for product and inventory updates and relatively high availability.
‫So for the low scale of merchants, we don't need many instances of the product management system.
‫Actually, a handful of them will probably be more than enough so we can place that service behind the
‫load balancer and run a few instances of the service behind it.
‫Also, we don't even need to charge the merchants database for the small number of merchants.
‫However, having a primary and a few replicas for high availability is definitely a must.
‫Similarly, we will place the products and inventory services behind the load balancer and allow for
‫automatic auto scaling based on the traffic to them.
‫Since we have only a few thousands of products, we will also not likely need a high degree of sharding
‫in those databases, if at all, for high availability.
‫However, we will also run multiple replicas of each database which will prevent data loss and help
‫with read performance.
‫Finally, to address the consistency, requirements will choose or configure the inventory and product
‫service databases to be in the CP category.
‫And that's it.
‫Now let's move on to the more interesting part, which is addressing the nonfunctional requirement for
‫our store front users and buyers.
‫In this case, we have millions of users from different countries with very high traffic peaks during
‫shopping holidays and flash sales.
‫We also have very strict performance requirements since our end users have little patience and can abandon
‫our store at any time.
‫For the storefront users, we need to provide availability, but for the buyers we need to guarantee
‫consistency.
‫And we also have very high uptime requirements since any downtime directly translates to a huge loss
‫of revenue.
‫So first, let's place the rest of the services behind the load balancer and provide the necessary redundancy
‫with auto scaling policies that allow our system to scale out substantially during peak traffic.
‫Notice that the order recovery and notification services don't require a load balancer since they are
‫subscribed to events from the message broker and don't get any HTTP traffic directly on the database
‫side.
‫We will have many search requests coming to the product search service.
‫So we want multiple replicas of our database running on separate computers.
‫And since availability is more important than consistency in this case, we will make sure that the
‫database technology is chosen or configured accordingly.
‫And similarly, we will replicate the Texas database for higher availability.
‫To improve performance, we can take several measures.
‫First notice that when a user requests a list of products, a subsequent batch of requests will go to
‫our object store to fetch the images for each product in the list.
‫This will significantly slow down the page load if we send back the original full resolution images.
‫However, we don't actually need to show the user the full resolution image for each product.
‫So instead, any time a merchant upload an image for a product, we can also generate a smaller thumbnail
‫and store it in the object store.
‫So when we need to show a list of products where each product image appears small on the screen, we
‫will send the thumbnails instead of the original images.
‫Of course, we can also utilize a CD end provider in addition to this optimization.
‫This will further reduce the response time and load the images to the user's device even faster.
‫In addition, some search queries for products will be very popular and it would be unreasonable to
‫perform these queries in the database repeatedly so we can add an in memory cache to the product search
‫service where the service can store a small list of popular products or results to those popular queries.
‫This will significantly speed up most of the search queries and result in better performance for the
‫user.
‫And that's pretty much all we need to do to satisfy the non functional requirements for the store front.
‫Regarding the non functional requirements for the checkout experience, we already did a lot of work
‫in the previous lecture.
‫For example, when users place an order, they get a quick confirmation from our system and all the
‫billing and shipping scheduling that involves third party APIs happen asynchronously.
‫Since we chose an event driven architecture to store our orders, we can easily handle a high spike
‫in purchases on our platform.
‫This way all the orders will get buffered in the message broker and we can process them as fast as the
‫external payment and shipping services can handle them.
‫Also, notice that our inventory service database is a key value store which already provides very high
‫performance due to its simple structure and lack of schema.
‫Now as the final step to improve our performance and availability.
‫We will run our system in multiple data centers worldwide and we will use a global load balancing service
‫to direct traffic to the closest data center to each user based on their location.
‫Of course, if one of the data centers experiences a power outage or some natural disaster, we can
‫always fall back to the other data center.
‫And we can do this because the global load balancing service is constantly monitoring the health of
‫each data center.
‫And that's it.
‫We finished addressing all the nonfunctional requirements for the merchants and the users, and we now
‫have a fully scalable, highly available and performant ecommerce marketplace platform, which is fully
‫distributed across multiple geographical locations and delivers a shopping experience to tens of millions
‫of users.
‫More importantly, you now have the process and the skills to design any system starting from very general
‫non technical requirements to a complete software architecture and hopefully completing these practical
‫examples added even more to your confidence.
‫I hope you had a lot of fun during the course.
‫If you haven't left a review yet, I would really appreciate it if you took a moment and left a review.
‫This helps me a lot and motivates me to create even more courses.
‫Best of luck to you and I hope to see you again for another learning experience.