System Design Interview - Notification Service
HTML-код
- Опубликовано: 27 сен 2024
- Please check out my other video courses here: www.systemdesi...
Topics mentioned in the video:
- Functional (create topic, publish message, subscribe to a topic) and non-functional (high scalability, high availability, high performance, durability) requirements.
- High-level architecture of a notification service.
- FrontEnd service host components (reverse proxy, local cache, logs and metrics agents).
- Metadata service, distributed cache, consistent hashing ring, gossip protocol.
- Storage for messages: SQL/NoSQL database, in-memory store, distributed message queue, stream-processing platform.
- Message sender service, thread pool, semaphore.
- Duplicate messages, retry policy, message order, security, monitoring.
Inspired by the following interview questions:
Amazon (www.careercup....)
Flipkart (www.careercup....)
Microsoft (www.careercup....)
Uber (www.careercup....)
This is somehow the best system design tutorial I've ever seen. Keep doing bro!
This is somehow one of the best feedbacks I've ever seen. Keep sharing your thoughts with us all bro! )))
2nd this. Not only for interviews, but also for day-to-day work! thanks.
It is.
@@SystemDesignInterviewthank you for making these videos! What would you recommend to learn these topics in depth? What do you personally use? Any good books, courses etc?
The best part of this channel is that Mikhail does not use ready-made solution available in the market. He shows us how to think simple and pushes for us to think what is under the hood. The thinking simple forces us to challenge our basics. Exactly what we need to prepare for System Design interview. Sadly, he has not been publishing any new videos for a long time now :-)
Glad you liked the channel, Hadi! Thank you a lot for the feedback.
I do plan to come back to RUclips with more regular video postings. Just need a bit more time to finish what I am working on currently. Stay tuned.
@@SystemDesignInterview appreciated with all the videos!
I had an interview at A Very Big Company that asked me a similar question and this video was extremely helpful.
Very glad to be helpful! Thanks for sharing.
Absolutely the best System Design videos on the internet. I especially love that the videos are kept relatively short despite the huge amount of knowledge and explanation. Waiting for the new videos! Спасибо огромное, Михаил!
These videos are really high quality and in depth. Haven't found any others diving deep into each individual component specially with options for each component and pros and cons for choices made.
Thank you, Jitu! Glad you liked the content.
Highly underrated content that is not just full of buzzwords.
Please keep it up. Can't wait for more uploads.
I feel, This channel is hidden Gem!!!
Thank you so much for explaining things in great details!!
Thank you for the feedback, Satyanarayana!
This is the most densely packed sys design video I’ve seen and it’s so full of good information. Really appreciate your work!
I have been watching Mikhail's videos for 2 years now, and they continue to be extremely valuable, and the best sys arch videos on youtube. If you can grok all of his concepts, you will be prepared. Still, it would be nice to see Mikhail cover some of the more advanced topics that the book "Designing Data Intensive Applications" discusses.
This is mind blowing. I didn't expected this kind of system design tutorial on RUclips. Your style to explain HLD and then deep dive into each component, Its awesome and hidden gem. Hats off to you. I know it takes lots of time to create such content but please try to upload more videos.
Thank you for the feedback, Dheeraj! Glad you liked the video!
Every second of this video is GOLD!
Glad you liked the video, Aman! Thank you for the feedback.
I was speechless after watching this video. There were so many details and though process being discussed in it, that I ended up taking more than an hour(while taking notes and capturing thought process). A great video covering breadth and depth. I know it would be extremely hard to make up this high-quality content, but I would love to see more of those.
Thank you, Hemant, for the feedback. Really appreciate your kind words!
finally, someone talking about system design who actually know how things work internally :-).
Kudos to you brother!
I'm glad that FPS Russia has found a new passion in systems design.
Great content! One question I had is currently frontend server pushes message to temporary storage and sender component retrieves message from temporary component. Here, we may need to keep watching the temporary storage to start the sender process. Instead we can take a hybrid approach. 1. All the publish() calls will be transmitted to sender component after persisting data in temporary storage. Now sender system acts on the task .
2. In the case of message failures, we will write that into a re-try queue and a re-try component which handles the request
" we may need to keep watching the temporary storage to start the sender process".
But isn't the Sender service(using threads pool) that handles if it wants to read the data? at 15:25.
Dude your videos are so good! Best systems design videos I've seen, love how you've especially tailored it for interviews. Thank you!
Where were you my entire life bro. This is so good.
Glad we eventually found each other ))) Thank you for the feedback, Dipendra!
Please Please keep doing this bro! This is the best system design tutorial I've ever watched.
Thank you, Desheng, for sharing the feedback! Much appreciated.
Another excellent System Design video: extremely thorough, detail oriented, and nailing both Functional and Non-functional requirements.
Appreciate the feedback, Salman! Thanks.
I browsed through 4 system design channels, you are the best so far
Best System Design channel. Very helpful. Please keep posting learning videos.
Glad you liked the channel, Shobhit! Appreciate the feedback!
Nice explanation. 👍👏
Often interviewers are looking for the entity models for the stored data. i.e. metadata for a subscription in this case.
It would greatly help to include those aspects as well.
Best system design interview resource online!!!! The only drawback would be the number of video :) keep up the great work!!
Thanks Yue Liang! Working on more videos. The next one will come out in a week.
Yue, got you here:)
I guess best System Design Interview Resource available. Thanks for creating this channel
Thanks a lot again for such a great channel. That's awesome. I'm in the middle of system design interview preparation and your channel helps me a lot.
few comments/question
1. as far as I understood, notification event that is handled by sender service gets endpoint information from metadata service. Let's consider a broadcast event (for example: sms storm warning, email from a system to all users about a new policy, etc) that has to be delivered to a number of endpoints > 100 000 or even more. If it is a 1 single event that is processed by 1 single node even in multi threaded environment, it would take way too long.
I'd probably generate those events that contain both - event and endpoint beforehand and speedup actual delivery. In even could not event itself, but just pair of two id's. This idea is based on assumption, that delivery itself is a more time-consuming operation than enrichment of an event with an endpoint information.
2. Regarding a temporary storage, you asked a very good question. The best that comes into my mind is probably a hybrid approach, i.e. having some key-value no SQL DB for failed events (that I'd redeliver later on) and Redis cache for everything else.
Hi quantumlexa. Apologies for the delayed response. And thank you for the feedback!
Your idea of decoupling event generation and the actual delivery is a good one. Please take a look at this thread, where we discussed resembling ideas: ruclips.net/video/bBTPZ9NdSk8/видео.html&lc=Ugzg_JJd9yUMUX9ySwt4AaABAg
P.S. Wish you all the luck on your interviews!
I just found your channel in 2022. You have made a lot of good system design videos. It’s sad that no more new video I hope that you can make more quality videos.
This is simply amazing. Thanks for making these videos. I think you should a write a book or create some paid tutorials. I would definitely pay for those. I am learning a lot through your videos already.
he has already a paid course bro.. buy it
@@pushpendrasingh1819 Thanks for letting me know. Seems to be a new creation. Definitely checking it out.
I just found your videos to help me study, they are the best in depth explanations!
Glad to be helpful, novaaaa. Welcome to the channel!
There is so much detailed and thoughtful information packed into every second of this video. Thank you so much 🙏
Thank you, Christopher, for the feedback!
I don't think people realize how much of the functional requirements tie in with knowledge of TOPIC BASED Pub-Sub. Quite in depth for something that's not explained.
I find part at 2:34 under explained.
A great resource for in-depth understanding of System Design.
You are doing a really great work. Thanks for compiling so much knowledge here.
Can't appreciate more 🙌 Kudos!
Pls make videos for 1.Design RUclips/Netflix , 2. Design Twitter/Facebook, 3. Design Yelp etc..
Very clear and concise presentation for a complex system. For the winner of Temporary storage I choose streaming solution like kafka, wanna know your lucky winners as well. Also I wonder whether the MessageRetriever's implementation actually varies based on the choice on temporary storage.
Agree with you, Xiaoyun. Here is my take on this:
ruclips.net/video/bBTPZ9NdSk8/видео.html&lc=UgwmaW3Ek0-XnkXb8KB4AaABAg.8tJRBPf4mun8tKuzz6sHVs
As for MessageRetriever's implementation, you are right, it depends on temporary storage we use and some other factors. E.g. whether order of messages is important. If it does, we better stick to a single-threaded retriever. If not, we can use multi-threaded message retriever.
@@SystemDesignInterview I was curious too - but, that link is taking back to this same video
Great step by step approach , It would be great if you can provide a link for the final design that viewers can keep it handy as a big picture while learning specifics/details of each sub-component . This recommendation/request applies to all of your system design videos
Hi Sharath. Thank you for the feedback!
Can you please clarify how you see it. Do you mean combine all components with their details on a single slide? Or you mean a text blog post version of the video? Or something else?
If you're using a message queue like Kafka or Amazon SQS, they already handle metadata storage. Then we only need to implement the consumers (i.e. the senders).
Thanks for the detailed explanation.
Thank you for the feedback!
very apt...keepup the good work..content always speaks
Thank you for the feedback, Harsha.
Great video! Keep up the good work! :)
Pros for using SQS: data size is small, no strict requirement around ordering for this problem, reliability. On the other hand, that raises several questions - when do we exactly erase the message from the queue. Only when all the tasks have picked up the message? What happens if one of the tasks fail.. etc.
It might also be useful to discuss about WebSockets for notifying the clients. I'm assuming that's what the tasks would ultimately do?
Thank you for the feedback, Saranya!
Agree with you. I should have extended the video to cover details of pushing messages to end clients (subscribers). Specifically, talk about HTTP polling (long and short), websockets, server-sent events. Let me leave this topic for a separate discussion.
Best Design tutorials, really helpful, Thankyou for making!
Thank you for providing a feedback on a regular basis!
What is the difference between the frontEnd component and API Gateway?
Absolutely Amazing ....I haven't found any other video from any other you tuber with such details. Thanks for the content. Are there any videos of your content which are not available in you tube,might be in udemy .I want to checkout out that as well. Kindly tell.
Thanks
The videos on this channel are one of the best system design videos. I wonder why you stopped doing them?
Would there be more videos coming any time soon?
Hi, this is one of the best videos I have seen. Can you make similar videos for WhatsApp & Twitter as well? I have gone through all your videos and they are all amazing. But I see you haven't been able to upload any video since past some time. A sincere request (and I think I can say this for everyone here), please work on more such videos. You are doing an amazing work.
Hi Hanspeter Pfister. Thank you for the feedback! I have both topics you mentioned in my TODO list.
I am pretty busy at work these days. But I keep thinking about all my dear viewers and will come back with more videos.
@@SystemDesignInterview Hey There - Hope you are staying safe - did you get a chance to action the TODO list :) ?
Hi Suren. Thank you for pushing me :)) Appreciate it :))
I am not yet working on topics mentioned in this thread. But I do work on more content. Let me not give you false promises and specify any dates. I do plan to create and publish videos more regularly. Waiting for these days to come...
Awesome system design tutorial.
Awesome tutorial
Thanks!
I have a question regarding the Metadata Service and its data storage. In the video, you mentioned that Metadata Service will be a distributed cache system, but you didn't mention what technology you will use or in which way you will use the cache system. I think that for the distributed cache system we could use Zookeeper (you mentioned this) and Redis (multiple nodes). The caching strategy will be cache-aside. For storing the data permanently I think we could use a key/value storage such as Dynamo DB. The key will be the name of the topic and the value will be a list of subscribers. If we need to store more information about the topic or the subscribers I would use a document based DB such as mongo/couch DB. Does this make sense?
Hi Milton. Thank you for the question!
All technologies you mentioned make total sense to me and can be applied here.
I like your thought process and attention to details. Keep sharing your thoughts!
Wow, this video and the channel is soooo helpful to me! Thank you so much!
Glad it was helpful! Thank you for the feedback, Xiangjie!
Great Content and and awesome explanation. keep doing more videos bro
I must say, this is amazing content(probably the best on internet) and you really are doing great service to job aspirants and distributed system enthusiast. I have one question, what would be the database schema for meta data database. I guess we are only storing topic and subscriber information in meta data database and in worst case(Cache miss) if we are calling database, we need to get all subscriber list for a topic really fast for sender service. Also in worst case, we need to do request validation(e.g. topic is present ) fast. What do you think should be the database schema for meta data service and also in what format we are going to store data in caching layer.
Any insights to this question?
Отличные видео, большое спасибо
Thank you so much for an informative video. I have a couple of doubts
1) When do we remove a topic from the temporary storage? How can we decide if all the consumers have consumed the data?
2) What should happen if a consumer got added for a topic in the middle? How should the task executor deal with this?
1. We can first disable the topic for let's say x unit of time ( could be hours/days etc). We would not accept new notifications for this topic after disabled. This way we'll stop processing notifications from senders end. The next thing is to remove the topic, which can be done by the user end after making sure about the pending messages , subscribers of the topic etc from the monitoring system.
2. since for each message, the subscribers list is fetched from the temporary storage, after a user has subscribed to a topic, the list of users for that topic must have updated in the metadata storage.
Hence whenever a new message came, the sender picks up the updated list (excluding the cache eviction and updation policies here) and start sending the notifications wrapping up it in a new task.
In the temporary storage, I am thinking Apache Kafka might be a good fit, since it can also handle streaming data
Good call! I also favor message queue and stream processing platform options. With already built-in mechanisms that many such systems provide, we may filter messages and apply transformations on top of it. And Kafka is a popular choice. One of the examples: www.confluent.io/blog/real-time-financial-alerts-rabobank-apache-kafkas-streams-api/
@@SystemDesignInterview Isn't this whole system developing kind of Kafka system?
Hi Shalin. Please take a look at this comment and the whole thread: ruclips.net/video/bBTPZ9NdSk8/видео.html&lc=UgxoaZ_vr1TFpHn6ynx4AaABAg.90FYh-PbeGT91FmzoWHuf-
@@SystemDesignInterview First, ask many have mentioned, these are incredibly good quality videos. Thanks for the significant effort that went into these. I have a follow up question. Is message queue the favored solution in this case because of the built-in mechanisms and popularity, therefore ease of obtaining information and support, or are there other wins such as performance, complexity or cost?
Unrelated second followup question: regarding ordering. In a real-world scenario, if I'm already in the AWS environment, is there any justification for implementing my own solution for FIFO queue when i can just pay more (apprently 20% more) for SQS FIFO? I have to consider additional resource cost and operational cost, and I have not crunched the numbers. But I was wondering if there's some other limitations or pitfalls of SQS. I think you may have mentioned something in passing in one of your videos but can't remember which.
Hi Miao,
One of the main benefits of a queue (e.g. message brokers, Kafka) is ordering support (at least on the partition level). Ordering is not always required for notifications, but is preferable typically.
Depending on the volume of messages, queue solution may be substantially cheaper than e.g. database. With the growing number of messages, queue solution helps to save on cost. Queue APIs usually allow to batch messages on both producer and consumer side, helping to save on number of calls, and as a result, the total cost.
Also, building notification service on top of a queue of some sort is a widely used pattern, I would say. For example message brokers (e.g. RabbitMQ), implement Pub/Sub mechanism by reading messages from a queue and pushing them to many consumers over TCP connections.
I have taken your system design course on Leetcode is hands down the best course (at least for me) in System Design. One thing I noticed about all of your contents is that you don't talk about the "Back of the Envelop" calculation. I personally think that its not necessary but would like to hear your opinion?
You are too nice it's fine
I will listen to sub titles
Thanks for the effort
Glad you found a way out. Thanks for the feedback!
I am waiting for more videos 👏
good job. very clear explanation.
We're designing a notification service, so a pub/sub service. And Kafka is mentioned as a potential choice for a message queue and stream processing platform.
But Kafka itself can be used as a pub/sub service, so maybe just use that functionality of Kafka instead? :)
Although Kafka only supports subscribers to pull data, no push support, so something to talk about.
This is a gem. Thank you so much!
super knowledged video
This is really great. The best system design video I found online. I am trying to find some information about : How to design a Google Calendar like system. Would you mind publishing a video on that topic ?
Thank you for the feedback, Xin! Added your topic to the TODO list. Please do not expect a quick answer though, the list is already quite long ((
Awesome way of explanation ...could you please start covering all system design problems asked in big4 and if u provide LLD also it would be awesome...
Hi Pranjal. Sure, there are plans to cover these topics. Just need to find more free time (( Unfortunately, every video takes a lot of time to produce.
Good explanation
This is awesome. I have some doubts at 19:29, there seems to be redundant components, When message retriever thread has got the message, then why to create tasks , it can directly send to the http,email etc microservices? What are we achieving by putting them in task creater and then running threads again in task executor which eventually calls other micro service. Seems over complicated.. One message retrieval thread will take message, and then it just send to the http or required endpoint.
Thanks for such detailed informative videos, these vidoes are helpful. Could you please make a video on SQL vs NoSQL? Also please provide tradeoffs and few examples in real applications.
Hi Chinmay. I plan a series of videos related to databases. Although, it will take some time to create. Stay tuned.
@@SystemDesignInterview Also can you please make a video on types of connections (https, tcp, socket etc) that can be used to connect client and servers for system design? It would be helpful if you could explain with different use cases/scenarios. (eg tcp is duplex etc)
How about having a queue in between the temporary storage and the sender service. In this way we do a fan-out approach where multiple sender instances poll the queue for messages and send it to the appropriate micro-service. The queue layer can be a distributed queue based on topics. This will increase the throughput of our service and also will be more fault tolerant as we would decouple temporary storage and sender components. Inside sender service as you mentioned we can still have the concept of task creation and execution to further increase throughput. Thoughts?
yes I have the same question as you, look at my comments above. However, I don' t think a msg que is necessary here, cuz in principal, the temporary storage is THE msg que. You can impl the storage with Kafka. You can also impl it with NoSQL but just use it as a msg que. IMO, msg que is for heavy write. Here for b/w temp store and senders, we don't really need heavy write. we can use heavy reads.
However, I do agree with you that, there should be and support multi senders instances.
Simply the Best (Y)
I love to use Kafka when I need a temp storage
Brilliant!
Excellent video! Excellent work! It would have been ever better if there was subtitles help.
Thank you, Nawazish, for the feedback. Much appreciated.
Will add subtitles to this and other videos soon. As well as new videos going forward.
It would have been super awesome if you had also included schema of what we are storing in database.
Upon revisiting, I think the requirements at 2:34 are very vague. For example why pub-sub with topics? That's assuming notifications need to be fanned out. For 1:1 messaging that need notifications, maybe individual queues would be better, and a producer/consumer style messaging?
thanks
Which DB we should we use as our Metadata DB? We talked about the MD service being a dist. cache, but what about the DB?
Number of writes to the database is relatively small, as writes happen when new topics are created or subscribers subscribe. There are many reads in the system, but only a fraction of those reads actually hit the database. As most of the reads are served by the Metadata Service (cache). So, both SQL and NoSQL can be used. If to talk about specific names, here is the possible list of options: DynamoDB, Cassandra, MySQL, PostgreSQL, Aurora. Personally I would favor NoSQL options for this use case (DynamoDB, Cassandra).
Hi, Thanks for the amazing content you've been producing. I have a question in one scenario though.
Consider the Task executor in the sender service has to executes tasks(send notifications) to 100 users and one of the threads failed to send notification to a particular subscriber (say subscriber no.33) and every other thread was successfully able to send notification to its corresponding subscriber. Now if we want to retry sending the notification to the failed subscriber(no.33), how do we do it?. We can just simply put the msg back in the temporary storage right, because the next time the msg gets picked by some other sender host..it again sends notification to all the 100 subscribers. So every subscriber apart from no 33 would receive the notification twice. How can we handle the case where only subscriber no 33 should get the retried notification but not others?
Am I missing something here?
the failed message can go to separate Temporary storage, typically called Dead Letter Queue, in case queue is used, with more metadata about the failure, and the task creator can create just one retry task for the failed subscriber
I think the front end service in slides should be named to backend service? Front end usually implies the user interface while backend is the application logic / controller / request processor
Thanks for the great content! I still have 2 questions that I couldn't figure out:
1. What happens when a message to a certain topic is delivered to some subscribers of that topic and for some it fails? How do we keep track to which subscribers a specific message was not yet delivered in order to deliver this message just to them later? do we somehow write this information to the temporary storage/metadata storage or maybe the task responsible for the delivery of each message stays alive and retries sending the message for a few days (sounds unreasonable) until successful?
2. When receiving a publish request why does the FrontEnd need to fetch metadata about a topic before storing the message in the temporary storage given that the Sender service anyways fetches this metadata again? Is it done just for validating that the publish request is valid (e.g., topic actually exists)?
Thanks :)
1) We can have a Audit Service to store the sent status. We can use Elasticsearch stack possibly (ELK) with date based index patterns. Because through this we can easily create visualizations,dashboards and do rich queries on the audit logs. Depending on the importance of the notification same can be implemented asynchronously or in the same send step.
2) There can be some business logic that need to be validated, Depending on the use cases this might not be required. An example of business logic can be you can't send more than configured notification in a minute or so per topic. This might need some interaction with metadata service.
In the "Temporary storage", do you need to differentiate some kind of messages? 1. Pending message (notifications waiting to be sent) 2. Attempted (being tried but not success) 3. Success 4. Failed?
18:10 is the key thought process for deciding on approiach in an interview... how would we do it as fast as you did???
I did not get, are all components within one server? Fox exmaple load balancer is Nginx as variant?
If the inter viewer wants a strict order of delivery guarantee. How can we ensure that?
Great question!
First of all we should clarify what order really means. There may be two options: publisher may have a custom order defined (e.g. each notification comes with a timestamp or some sequence number) or order is defined by notification service (e.g. the order of requests, first come - first served, FIFO). The former option can be treated as a special case of the latter option. Or in other words, if publisher has some special order defined, it should be publishing requests in this order. And if our notification service supports FIFO, requests will be processed exactly in this order.
How to implement FIFO support for the notification service? When requests from a publisher arrive, the notification service needs to store messages in order in the Temporary Storage. What storage types support ordering? For example Apache Kafka. Kafka only guarantees ordering within a single partition. So, if we store all requests coming from this publisher in a single partition, ordering is guaranteed.
Now we need to read messages from Kafka one by one and send to subscribers. To preserve order of messages, Sender service should be a single-threaded component. One instance of Sender per Kafka partition. Sender simply serves as a Kafka consumer. It reads messages in a single thread one by one and tries to send them.
The tricky part is to understand what to do with failed messages. If delivery of the message fails, we need to decide how to handle such use case. We can skip this message (send this message to a dead-letter queue to process it later) and move to the next message in the partition. In this case we may break the order here, because failed message may be re-delivered later in the wrong order.
In general, it is hard to achieve ordering when we have multi-threaded publisher and multi-threaded sender. I should have a separate video on this, to explain it visually. It is easier to explain using specific examples. So, to achieve ordering we usually deal with single-threaded publishers and consumers. But this decreases throughput of the system. Tradeoffs, as usual.
@@SystemDesignInterview good analysis man, as usual
Thank you, Labandusette!
I'm a little confused why it's talking to frontend service, shouldn't it be backend since it's making a call to send a notification?
Fantastic explanation.
I just have one question. What is the usage of calling the metadata service from frontend service if we are not using the data to send it to the downstream services and we are anyway calling the metadata service from sender service.
Hi Saikat. Thank you very much for the feedback!
Please take a look at my response in this thread: ruclips.net/video/bBTPZ9NdSk8/видео.html&lc=UgyCIBZD38Zvib7Gf-Z4AaABAg.8zF3OPIIMqv8zR54tNr8mP
Great Tutorial, thank you so much.
I have a question in the case of publishing a message, does FE service connects to Metadata service, if yes then for what purpose?
nice video. @13:40 , i think Casandra is not columnar database,its row oriented.
Thank you for this immensely useful System Design video.
I am thinking on how to make the message delivery ordered. The publisher sends a increasing sequence ID which needs to be preserved when receiving messages from the subscriber.
In this case,:
- the Sender service has to keep track of which messages have been acknowledged by the subscriber via an Ack mechanism.
- the Sender has to query the Metadata Service (which contains all the sequence IDs that are to be received by a Subscriber), and ensure message with ID1 has been acked before sending next message in the sequence ID2, where ID1 < ID2.
- Any one message delivery issue with stall the delivery of all subsequent messages, so the Sender Monitoring system should inform the Subscriber of this stall via an email or something else.
Any thoughts on this ?
Thank you for the feedback, Rohit!
I like your thought process. The algorithm you described will work. But it may be hard to scale. Let me share with you some thoughts.
To implement ordering, we need every component of the system to carry some burden. Yes, we can say that publishers are allowed to submit messages in any arbitrary order, specify some ID (sequence number) for each message and leave all the complexity for the notification service. Notification service will then track incoming IDs and hold messages. For example, if message with ID = 1 came and then message with ID = 10 came, notification service needs to hold this message until messages with ID = 2, 3, .., 9 arrive and processed. This may lead to many messages sitting in the notification service waiting for its turn.
Alternative to this approach is to tell publisher to share responsibility and submit messages in the order they need to be send out. Notification service needs then to preserve this order. And Sender needs to send messages in that order. We can use Apache Kafka as a Temporary Storage, to preserve order (per partition). And Sender becomes a Kafka consumer, that read messages one-by-one in a single thread and sends data out.
Please check other comments for this video. I have recently replied to another question about ordering. There are some more details there.
2:26 Functional
- publish(topicName, message)
- subscribe(topicName, endpoint)
Why only subscribe need the parameter endpoint? There are some difference between publisher and subscriber communicating with the service?
Can someone help me figure it out?
Thank you
Thanks.
One more clarification: In the end when you show subsriber A, subsriber B those will be actually individual micro-services which would support different ways of notifications for example SMS, HTTP endpoint email, push notifications etc and even those services will need access to metadata service as metadata service stores the list of actual subscribers for each topic correct?
Thank you!!!!!!
Could you show some light on how to scale 'Sender' horizontally and how 'Sender' is reading the messages from temporary storage?
The sender service is also a distributed service. When we have many senders, how do we know or make sure that there are no more than one sender, sending the same message?
Thanks for the nice video. Have a question: how does message retriever get message from temporary storage? If temporary storage is a database, I wonder how we get data from this dB? Just randomly select some non-processed message from it?
Hi Xinlong,
Let me answer your question by providing references to some of my other answers. Please take a look at those and let me know if you have more questions:
1. ruclips.net/video/bBTPZ9NdSk8/видео.html&lc=UgwBRCTc8YW3n7iWS3t4AaABAg.959L9KgaBem95Hj6adrwEL
2. ruclips.net/video/bBTPZ9NdSk8/видео.html&lc=UgzVKkaCFS4pr4H4ywN4AaABAg.95K4TxO_5zi96Hhv5bCGbL
Thank you for great video. But when message removes from temp storage? what is policy?
WONDERFULL THX.
Have one question - In the Sender service, lets say a task executor service host CRASHED, how the system make sure tasks in the failed host are taken care ?
How we can deal with duplicate read problems in Horizontal scale Sender Service in the case of Key-Value Database as Temporary storage?
I am getting started with System design, can someone explain what is frontend service after the load balancer? In a usual web development context, we use the frontend term for clients but I am assuming it means something different here? I love how detailed these videos are but struggling to understand this one and Distributed Message Queue because of this frontend service. Any help is appreciated.
Great video so thank you! However, I'm a little confused. You list the Frontend service responsibilities (~5:24) including SSL termination, authorization, authentication, request dispatching, ... and then (~7:40) describe it as processing the message. Is that right? Initially I initially understood your definition of Frontend Service as an API Gateway. Later I understood it as a Message Processing Service. Are these one and the same thing?