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..

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

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.🙌

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.

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

excited!

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.

This is super helpful. Thanks

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?

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

@ThinkSoftware

Жыл бұрын

Thanks for the comment 😊

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?

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.

really liked your crisp explanation

@ThinkSoftware

Жыл бұрын

Thanks 🙏

Thanks

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 🙂

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?

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.

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

6 ай бұрын

yah , data can be retrieved from message queues.

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.

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

20 күн бұрын

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

@davidoh0905

20 күн бұрын

kzread.info/dash/bejne/kZZqqNCidc3Pgpc.html This video is a great supplement to the current video!!

Watched. --

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

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?