yes it is very good talk but it not clear what is the throughput of the system with 84K clients, I guess it is very low if he was saying the CPU was barely used.
@@mat822 125 million users, 1 push notification per day, each notification takes 1KB 125000000*1024/86400 < 2MB/s negligible throughput. Of course they kill connections periodically, but still very low throughput system.
nit pick here, but how does sharding for availability help in push registry feature checklist? Its because it protects by only some portion of connection server goes down?
Question : when you say client opens connection and stays connected to that server, wouldn't it talk to load balancer and not the actual server here? So even if you deploy new server behind that load balancer there won't be any issue of the connection closing and re-opening as you mentioned? Please shed some light if I am missing something here.
Amazing talks! I learn a lot from this video. "Ask client to close" is really brilliant. Randomized the connection time is also very impressive. I have seen random backoff algorithm, don't know it can also be used in this scenario.
I have only one request why the client depends on the server. I mean why this client-server mapping. What if the server is down then we need to migrate all the client-specific servers to a new server which is costly and may create issues like thundering. It's not we should make the server stateless with client requests and maybe only we should store client information in the push registry?? and when push notifications just randomly pick the server and send a message to the client id.
with push client subscribe to a small set of keys( movie name …). while with kafka there is a single log and client need to read all message that have been written to the log
Much better than watching "Design a Notification Service" System design interview videos.
The “ask client to close” due to TCP wait avoidance, is brilliant. Well done!
This talk is so good. Especially the mention of benchmarking numbers.
m4.large ~ 8G,2vCPU = 84000 concurrent connections. ❤️
yes it is very good talk but it not clear what is the throughput of the system with 84K clients, I guess it is very low if he was saying the CPU was barely used.
@@mat822 the system does look io intensive (mostly network calls) so low cpu makes sense i think
@@mat822
125 million users, 1 push notification per day, each notification takes 1KB
125000000*1024/86400 < 2MB/s
negligible throughput.
Of course they kill connections periodically, but still very low throughput system.
I am watching this right before a system design session! :)
Same lol
Brilliantly presented!!! Thank you!
Extremely well conducted video, very informative and explained without any wrinkles. Kudos!!
Reminds me of backpressure, ofc not the same here.
Really neat presentation with much informative content.
Excellent presentation. Thanks for getting into implementation details!
nit pick here, but how does sharding for availability help in push registry feature checklist? Its because it protects by only some portion of connection server goes down?
Great work to figure out asking the client to drop the connections and also scale on connections per seconds.
This a great talk that really warms up after 20 minutesin when the talk goes into operation details.
I think some confusion at ELB. ELB operates at Layer 4 which means at the TCP layer already.
One of the best 'Notification Design videos' seen so far.
Question : when you say client opens connection and stays connected to that server, wouldn't it talk to load balancer and not the actual server here? So even if you deploy new server behind that load balancer there won't be any issue of the connection closing and re-opening as you mentioned?
Please shed some light if I am missing something here.
Super comprehensive and very inspirational! Thank you.
This is an insanely good talk.
Amazing talks! I learn a lot from this video. "Ask client to close" is really brilliant. Randomized the connection time is also very impressive. I have seen random backoff algorithm, don't know it can also be used in this scenario.
This has been so insightful
Thank you so much for this talk!
Very good talk. I also liked some of the questions in the end.
Every bit of applause deserved for such a verbose explaination.
It's truly comprehensive. Thanks for the nice presentation in a very understandable way.
what a great talk. so dense, no fluff
Very nice presentation
Excellent presentation!! Lots to learn
What an amazing speaker this guy is
Brilliant Talk.. Learned so much.. Thanks Susheel.
Just Amazing! 👏
TCP TIMED WAIT avoidance was brilliant
How can they "push messaging" to Android with WebSocket while Google simply banned any push notification methods but FCM?
This push mechanism is for users who are using the app. FCM is used for both forground/background usage.
Excellent presentation with enough in-depth details and nice insights!
Really good explanation. Literally clapped at the end :)
I have only one request why the client depends on the server. I mean why this client-server mapping. What if the server is down then we need to migrate all the client-specific servers to a new server which is costly and may create issues like thundering. It's not we should make the server stateless with client requests and maybe only we should store client information in the push registry?? and when push notifications just randomly pick the server and send a message to the client id.
Really thought through presentation
great talk, thank you!
Thank you so much for this talk !! very well explained ...
Neat presentation and insightful.
Great Talk
Great presentation.
Awesome talk! Enjoyed it.
Brilliant!!
Great talk, very detailed
wow, what a great talk, explains really well!!
Love this talk
Excellent
Great talk! Very inspirational!
Such an awesome content , thankyou
what is the difference between push vs kafka messages/ message queues?
with push client subscribe to a small set of keys( movie name …). while with kafka there is a single log and client need to read all message that have been written to the log
Very Good. thanks for sharing.
Excellent presentation !!!
what is worse than thundering herd?
its recurring thundering herd
Hearing all this talk of massively scalable is getting so nauseous man, fk this shit
stop moving the camera, already got motion sickness.
Tip : Watch at 1.25x speed.
man this is cool and all but all this work is just so you can say "hey, we think you might like this anime" ?
Thank you! Very informative presentation.