![]() The total storage requirement would be = 60 billion * 200 bytes = 12TB. Now, let's assume the average URL length to be 120 characters (120 bytes), and we add 80 more bytes to store the information about the URL. Then, the number of URLs we will be storing would be = 500 million * 10 * 12 = 60 billion URLs. Storage Estimation: Let's assume that we are willing to store our data (short URL + long URL) for ten years. Considering the 100:1 read/write ratio, URL redirections per second will be = 100 * 200 URLs/s = 20K/s.If we calculate this value for each second, i.e., queries per second (QPS) = 500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/s.With a 100:1 read/write ratio, we can expect 50 billion redirections during the same period (100 * 500 million = 50 billion). Traffic Estimation: We can assume that we will have 500 million new URL shortening requests per month. Database: It will be used to store the mapping of long URLs to short URLs.Web Servers: Multiple instances of web servers will be deployed for horizontal scaling.Load Balancer: To distribute the load evenly among the backend servers.They will communicate with the backend servers via the HTTP protocol. The following are the key components of the URL-shortening application: We will assume that our read/write ratio is 100:1. The most important thing to keep in mind here is that our system will be read-heavy, meaning the number of read requests per second can be up to 1000 times greater than the number of writing requests. ![]() This section will examine the estimate of the number of monthly requests, storage, and so on.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |