Another great video. Happy to report this is exactly the architecture I would have drawn up, so that's progress from some months ago. (Except maybe for the time series db.)
imho, the downside of the timeseries db is that you will repeat calculations every time you want to know the total downloads or the top ones. In that case, I would have stored the data in the database on a field that counts the total downloads and then search from there. The issue in this case is that you will probably have deadlocks or concurrency problems because of the reads and writes, mostly on the top used apps. in this case, the db should be sharded so reads occur in one db shard and writes on the other ones. then automatically the db will update the data from one shard with the other ones. Aside from that, great design and i think the combination of db and elastic is a great choice
This is a great thought. Unfortunately sharding here will not work--we can't distribute a single row. However, if we're willing to sacrifice consistency, adding a simple TTL cache of the total downloads for each app would be a good way to solve this. Thanks!
We have a full course on our platform that's designed to teach you all the fundamentals of system design from the ground up! We also have much more in-depth problems than this one that dive into the specifics of how a system like this would scale at a low level. Think of this video as a teaser--if you liked it but want to dive deeper and learn about the concepts behind this design, you should sign up! Thanks for asking :)
Another great video. Happy to report this is exactly the architecture I would have drawn up, so that's progress from some months ago. (Except maybe for the time series db.)
Great, thanks!
imho, the downside of the timeseries db is that you will repeat calculations every time you want to know the total downloads or the top ones. In that case, I would have stored the data in the database on a field that counts the total downloads and then search from there. The issue in this case is that you will probably have deadlocks or concurrency problems because of the reads and writes, mostly on the top used apps. in this case, the db should be sharded so reads occur in one db shard and writes on the other ones. then automatically the db will update the data from one shard with the other ones. Aside from that, great design and i think the combination of db and elastic is a great choice
This is a great thought. Unfortunately sharding here will not work--we can't distribute a single row. However, if we're willing to sacrifice consistency, adding a simple TTL cache of the total downloads for each app would be a good way to solve this. Thanks!
great video
Hey guys, what is the purpose of signing up if you are putting all the videos out for free?
To support i guess?
We have a full course on our platform that's designed to teach you all the fundamentals of system design from the ground up! We also have much more in-depth problems than this one that dive into the specifics of how a system like this would scale at a low level. Think of this video as a teaser--if you liked it but want to dive deeper and learn about the concepts behind this design, you should sign up! Thanks for asking :)