After identifying the entities and operations, the last step in defining the workload for the bookstore app is to quantify read and write operations based on their frequency. We also need to determine whether our application, on average, performs more reads or writes, so we can choose the best data model for the workload. This is important because write-heavy workloads are more resource intensive than read-heavy workloads. Before we quantify read and write operations, it's worth noting that operation frequency rates are estimates, based on data collected by stakeholders and how we expect users to interact with the application. We'll record the frequency of operations in this table by adding a column called rate. Let's get started. We'll begin with operations on the e-book, audiobook, and printed book entities. When a user clicks on a book, the app will fetch the book's details. We expect to have around 10,000 concurrent users who click on more than one book per session. So we'll estimate that this operation needs to run 1,000 times per second. The next read operation retrieves an author and their book titles. We'll estimate that this operation will occur 50 times per second. Our Ops team requested that the read operation, which retrieves a stock level of printed books, occurs every 12 hours or twice a day. Now let's quantify the write operations for the e-book, audiobook, and printed-book entities. First we will need to add and update books. We'll upload all the books at once, before we launch the app. But after this, we can set our estimation to 10 times per hour, since adding and updating books won't be a primary function of the application. We'll set the rate for the operation that updates the in-stock quantity of printed books whenever we sell a copy to five times per second. Let's move on to the operations that involve the reviews entity, starting with reads. Our app will fetch 10 reviews at a time to support pagination. When viewing a book, we expect users to click on the reviews tab 20% of the time. So we can estimate that this operation will be used 200 times per second. We also need a write operation to add a review. We forecasted one billion reviews after three years. So we'll estimate that this operation should add 50 reviews per second. Finally, let's move on to the operations for the user's entity. For reads, we need to fetch a specific user's details to display on their profile page. This won't be done frequently. So we'll estimate that this operation should run five times per minute. We also need to add new users and update existing user profiles on the application. We expect this to occur often to accommodate a growing user base. So we'll assume that this operation should run once every second. Now that we've quantified the operations, let's examine our findings to determine how we should optimize our schema. For reads, fetching book details or reviews are the most frequent operations. For writes, adding a review is the largest write workload by a substantial margin. We'll need to optimize for both reads and writes, which we'll learn how to do when we select the relevant schema design patterns. Great work. In this lesson, we quantified the read and write operations for our workload. This information will be very valuable when we create a schema for our data.