Twitter Likes Count Design | Youtube Views Count Design | Near Realtime Counter System Design

[@ThinkSoftware]

Let me know if you find this video useful. And please don't forget to like the video and subscribe to this channel. Thanks :)

[@AnkitJain-ln7gx]

This is nice explanation. I would like to see design of digital wallet which cover transfer, topup and withdrawal usecase and talks about concurrency and data consistency for users..

[@abhijit-sarkar]

You ask many what-if questions, but answer none. You also don't justify any of your choices (such as creating the 3rd table instead of updating tweets table). This is not a quiz game; the video is not self-contained.

[@bipulmishra1543]

I have seen a lot paid and free courses on youtube. But luckily I have came across your channel recently when searched parking lot problem. Keep up doing the good work. Hats off sir.🙌

[@Wheyong]

i would choose eventual consistency in this case, because the exact number is not that important to most users. eventual consistency will make scale of likes count easier

[@manmohanmundhraa3087]

your questions in this video is quite intuitive. i am sure by asking right questions many will be able to think in terms of solving problem while continuing watching.

[@rahul10anand1]

Thanks for covering the breadth of the different solutions. You started with brute force and worked up to suggest some kind of an optimal solution. However, rather than telling the "WHY" part of choosing a design pattern - you are leaving it up to the viewers to interpret and decide. Would have definitely subscribed and liked your content for wholesome information and depth.

[@code-master]

Excellent and thought provoking, I like your teaching style where you answer and give thought provoking questions.

[@gurmeetchawla8362]

I want to thank you for your video , but i am a bit disappointed at the way you ended the video abruptly. You did not complete the video and close the question in discussion. It seems like you have a paid service somewhere you answer all these questions or are preparing that for future. Kindly share your thoughts.

[@ThinkSoftware]

I do have a paid service but some of the questions could be topics for more videos.

[@davidoh0905]

@@ThinkSoftware yeah overall good start and everything but the last bit was a big disappointment, to be honest :(

[@davidoh0905]

kzbin.info/www/bejne/lZOZd6Gfes-ciJY This video is a great supplement to the current video!!

[@computerscientist9980]

excited!

[@davidoh0905]

so I am not sure how things are concluded. is the cache going to hold counters for all of the history that ever exists? and there's two types of consumers? one that writes individual like records to DB and one that stream aggregate and update increments to the Distributed cache?

[@andriidanylov9453]

Appreciate 👍for sharing. Approach with likes in separate service looks better for me.

[@ThinkSoftware]

Thanks for the comment 😊

[@heykalyan]

really liked your crisp explanation

[@ThinkSoftware]

Thanks 🙏

[@jlecampana]

Great video! precisely what's needed for interviews, thank you sir. But I was left with the doubt of what to do If a consumer dies in the middle of processing a like. I guess the answer is that Messages in a queue can be re-tried?

[@User-nq9ee]

yah , data can be retrieved from message queues.

[@beinspired9063]

Hey...I loved your videos, they are really helpful. Special thing is you ask a lot of questions during explanation and open my mind to think beyond one way of thinking. My question is - where do you discuss these questions which you ask in your videos? Many thanks... wishing you good health and wealth 😊

[@ThinkSoftware]

Thanks for comment 😊. I am looking at various options for that.

[@yjeeeek]

13:47 if you use kafka and your consumer manually commit offsets, then after consumer died zookeeper will re-arrange topics and assign the topic to another consumer. new consumer will continue from last comimted offset. considering that, we may want to put all the updates regarding the batch into single transaction, rather than do atomic updates for every tweet.

[@jiaweiwu9857]

This is super helpful. Thanks

[@gmmkeshav]

one corner case that you have not taken up sir what if a person again clicks on the like button to dislike the tweet how will you remove the like?

[@Wheyong]

regarding adding a field to. tweet table vs like count table, i would choose like count table, the reason is that it will reduce a lot writes/update the tweet, otherwise it could be a performance issue. I would like to hear what you think?

[@ThinkSoftware]

thanks for the comment 🙂

[@vikasgupta1828]

Thanks

[@yujiahe4190]

A question about write-through cache to distributed cache at 14:09. will redis node die before responding to MQ, will a single record be counted multiple times in this case?

[@szyulian]

Watched. --

[@ss_lemonade]

A question about the example sql queries done at 11:20: is the "SELECT ... FOR UPDATE" statement still needed here when the UPDATE query would trigger an exclusive lock on the Tweet_Likes_Count row for tweetId "abcdefghij" anyway?

[@ThinkSoftware]

Yes because select and update are two different statements so it is possible that multiple threads run select in parallel and get the same value for the count and then all try to update count = count + 1. In this case, they all will change the count to the same value although it may need to be updated to count + X where X is number of concurrent calls coming at that time.

[@ss_lemonade]

@@ThinkSoftware In mysql at least, I believe an update statement that does a query like "count = count + 1" would be atomic. A "select ... for update" would probably help if you needed to do additional work with the selected value afterwards, or if you wanted to update the column manually using the current selected value

[@ThinkSoftware]

It all depends on DB transaction isolation level. With serializable isolation level, it may work but not with other isolation levels.

[@shubhamsoni6013]

06:50 A service should be responsible for single task, so we must create a separate service for tweet likes. Assumption is that tweet create service have a less load but tweet like service has huge load so we can scale those services separately

[@genteka5106]

Wish that you say less about stuff everyone already known

[@i-am-darshil]

Every tweet will have the tweet_like_count field. Shouldn't we add the tweet_like_count field to the existing Tweets table? What are the pros of creating a new table?