What a lovely Sunday afternoon rain cup of tea and 2 brilliant youtubers collaborating to make a very interesting system design video cant get better thank you😍
@@KeertiPurswani maam could yout make a coding interview video with aditya verma,He is just great and his way of explanation is just on another level . so Plz plz make a interview video with him.
I work in Outlook Calendar team, handling recurrence is a nightmare for us as well xD. Recurrence is handled by recurrence blob which is present in master item/1 item which is a serialized sting which contains things like start date, end date. And all the events can be expanded just by this recurrence blob. If now suppose one ocuurrence is deleted/modified that will have a separate calendar item, attached to master item. This is how it works in outlook today :)
Generating Event ID: You were thinking right that no event, even in frontend, should be there without any id. Gaurav was also right in deciding that it'll be better if the id is generated from backend (incremental keys if SQL). To, combine both - After user inputs the data for new event and clicks create button, we won't show the event created in frontend (maybe show an outline in dimmed color). We only show that created event normally when we get all the details back from the backend. Until then maybe run a loader, the turnaround time should be quick though. Recurring Events: Hmm this seems hard, :-p I'll just keep one object for recurring events and calculate all events within a given period from that only when queried for. This way we can support never ending recurrences. If any of the occurrence of a recurring event changes, we can create a different object altogether for that occurrence. But to keep it connected, it'll have recurrenceID as the eventID of the parent recurrence and normal random/incremental EventId as unique id. Maybe we could keep these in a separate table itself in db. For the parent event, maybe we could keep a flag like hasRecurrences set to true, so that while getting those, we'll calculate all events that need to be sent to backend. We may need to keep another field like originalStartTime in occurance obj. so as to replace the original one calculated with this occurence when calculating all events from recurrence Event. cancelling occurrence - create new event as mentioned and cancel that one changing time/other details - create new event and change details in that getting events - get all events. if any hasRecurrences then find those from recurrences table, replace with calculated instances and return the list. Hopefully we can get everything done with this design, although it might need some case handlings.
For handling the recurring problem- when we set an event which is recurring keep all the ids of recurring event same as the first one. If user wants to update a particular event, keep a flag asking do you want to change this in all future events or only for this one- if flag get yes then no problem as it has same id it'll update for all else if only for that one then on updating should change the id of that particular event with a new id. By keeping the same id it'll also help in deleting all recurring events at once(we can use a flag on deletion also). This is my first time watching any system design video and it was really fun watching. Now I'll deep dive into system design ❤
Manager can maintain queue/priority queue and will have only one event which is about to occur, when it's get removed from the queue, it notifies to user and adds next going to occur event back into queue. this way we can avoid maintaining all event duplicates. This even helps in multiple notifications for the same events in case of all day event by pushing back same event into queue and even changing only one of the event occurence with some override flag.
I think a calendar event either can be a normal event or recurring event, we can store recurring event in some other data object or table with start and end data+time, this way once you try to find user events, you can check normal events and recurring event from different sources and plant the details to calendar accordingly. This way you will have more control over calendar events.
Great discussion. I would like to appreciate your efforts. I would love to have a follow up video on this, when we have a room for an event. And how double booking of room will be avoided, how concurrency will be handled in this system
For recurrence, maybe one ID to identify the parent/series, and one sub ID to identify each individual instance of the recurring meeting. That helps toggling if you're dealing with the whole series or just one instance
Recurring event: - Event class: Add recurringId - Create recurring event: In EventService duplicate the event with same recurringId but different eventId, and store all events into a list - Update recurring event: Add a flag 'isRecurring' for client to choose if all recurring events are to be updated as well. If isRecurring=false, the updated event is still part of recurrence. - Delete recurring event: If flag isRecurrence=true all the events with same recurringId get deleted. Else, only a single event get deleted and is removed from the recurrence.
Great video Keerti. Here's my approach. EventDetails could be a child to Event and whenever you change a particular occurence of a recurring event, you create a new EventDetails object as a part of mutating an Event object. If you want to update all future occurences, you create a new EventDetails object and bulk update all Events to have this new EventDetails child object instead of editing the original because that would mutate past events as well. This also solves the "Event object without id" problem on the client side, you could send EventDetails object or a new object EventRequest. Also, the events could be lazy-evaluated(created) by creating first N out of total E events, marking some Xth last event from the last Nth event(N-X) with a flag attribute, then use this attribute to trigger creation of the next N events on EVENT_END event(topic event, not Event) until all E events have been created, it would also work for never ending events. State for recurring events, requests rather, can be persisted using RecurringEventRequest object. Did I miss something? I probably did :P
We could have a UserManager which will have the user deets and the calendar object and the EventManager can then query the calendar object from the UserManager and then get the list of events, which will follow Single responsibility principle as well!
Great work Keerti. Really appreciate the effort you are putting on both the channels. Managing work and youtube is itself a great feat and that too doing it regularly while maintaining quality is plainly superb. It's been 8 years in IT and watching your videos has motivated me to try learning about DSA. Have started my DSA journey by learning from your other channel.
Love the video, love the attitude shown especially by Keerti here! Although "shooting ideas" has it's own place sometimes when quick action is needed, but in most cases, an insightful approach and "stable" thinking is better suited to get to mature decisions. Better not trip over and entangle ourselves into complexities. Many thanks for the video!
I have one question, why in whole video we tried to focus on creating object for response for example EventId (acting as both response for UI and domain for creating an event) and doing creation operation on that only. Why cant we have two objects like one will be domain and other will be response object out of it once core logic is written. Actually, according to my understanding we should always have two POJOs for different purposes. LMK What you all think?
I love how a process that is intrinsically a hard slog is made so enthralling. I was literally on the edge of my seat following along the merging of minds in this colab. So glad I came across this vid. Something to sink my teeth into - "all animals have teeth - but do they all chew ?" I never knew design was such an engaging and entertaining process! Its left me chained to polling this channel Def recurring.event(vid=True):
For recurring events we can make a single event and store the criteria for genrating future events event maneger will tale care of generating the event for read apis etc if a single event needs to be updated, we can make the actual event and store it actually in db otherwise for the rest we will relay on manager (basically for the events in which user do any operation we will actually store the event in db otherwise it will just be computed with a cron logic)
I have been searching content for a lot of time on low level design. I just fall in love with your design patterns Playlist and enjoying this 😍 video with my coffee ☕️ and learning a lot.
I really learn fast when I see things in action rather than reading about them. This video really helped me understand how to approach the problem and how to keep the discussion with the interviewer.
Enjoyed the video. But you are using hashMap to store data in-memory which is the thing for LLD and then u suddenly talk about databases and indexing. Isn't it contracting?
@KeertiPurswani We'll create a single Event, and when we have to update an event for a particular date (let's say 29/04/2023), we split event in three parts: 1. before 29/04/2023 2. for that date 29/04/2023 3. after 29/04/2023 (which details will be same as (before 29/04/2023). Basically, update the recurring end date as 28/04/2023 in existing event and create 2 new events, one for 29/04/2023 and 2nd for upcoming dates (after 29/04/2023). This way we can save lots of memory and also able to handle the case recurring end date 'NEVER'.
I have a doubt, you mentioned we will store metadata or link metadata in treeset, if we will store metadata then we have to do update that's fine but how all will be pointing to the same metadata object? will we be having a different map which will store some id with metadata and we will then store that id in our treeset? Maybe I understood it wrong, please clarify what exactly is the meaning of that each entry will point to same metadata object?
maam there is no video on Aditya Verma Coding Interview and he is great coder so could try to make a video with him , He is just great and his way of explanation is just on another level . so Plz plz make a interview video with him🥺
Good explanation.. I have one doubt here when u say having userid in a map, is it like when server starts reading all user details from db with event metadata and keeping it in memory?
wrt recurrence relations between events, how about we store only the first event that the user creates as a recurrence event, take in the rec_freq and num_of_rec_events; based on these facts we will create the future events(Note: we won't store them as seperate events, some client side processing is involved but thats okay). Also when the user wants to change an event which is a part of recurring event; if the user wants to change just this one event, then we just create a new event, otherwise if the user wants to update all the events following this event, then we only have to update the one event we has stored.
First comment on any video. But can't control. @Keerti, i didn't get why said we should have ids generated on the frontend. IMO, Ids generated on the frontend sounds like a bad idea to me. Less control on the client is much better. When you call booKEvent api. You are making a POST request. Backend should generate it and persist it. For POST Request we use "Location" header. In the response, client should get Location Header which has read url (GET request) of this event. Why bother about id in the response. This location url might be (event/{id}) or anything.
Enjoyed the video and the discussions very well . It felt like I was brainstorming along with you two . You don't usually find quality LLD videos that much in the internet compared to DSA . Please bring more quality content like this
Hii mam I hope you are doing well . I have a question .can I join scaler academy after completing 12th . your answer is yes then tell me what is duration and course fee 🙏🙏🙏🙏🙏🙏
store the events for short time range like for 1 month or 6 months. Render the future events based on the cron expression only. If user changes the future events like updating description/titles then only create the respective which user has updated. Great content !!😄
Hello need a advice Hello just need advice from you.. Hello ...i m 28 from commerce background wanna do full stack devloper but like tech person theyvhave to start from ground i m from non tech i hv to start from underground level..can u suggest should i do basic fundamental of computer application networks basic database, excel ,adobe photoshop canva illustrator like basic of operating system what u suggest or i should start from basic undertstanding of operating ssystem computer application computer network databasesp before entrying in full stack developer course Or should direct start from HTML CSS JAVA SCRIPT
@keerti I could also feel the conflicts in gaurav's mind, thinking too fast, happens with me also. Lastly I have gained a lot of respect for google/Teams calender and meeting feature.
DIDI PLEASE HELP ME I'm getting METALLURGY at MNIT JAIPUR and CSE at some other tier 3 colleges basically state government universities and in some iiit but are very costly. Now I'm worried what to do as I want to work like you as a SDE. Please help me out.🙏
Great content but my thoughts. Two experts took more than one hour barley covering the system. Imagine handling this alone in under 45 minutes. Take away: If you have not prepared well and practiced similar design in your past, then you are screwed :/
What a lovely Sunday afternoon rain cup of tea and 2 brilliant youtubers collaborating to make a very interesting system design video cant get better thank you😍
Hope you have fun ❤️❤️
@@KeertiPurswani maam could yout make a coding interview video with aditya verma,He is just great and his way of explanation is just on another level .
so Plz plz make a interview video with him.
I work in Outlook Calendar team, handling recurrence is a nightmare for us as well xD. Recurrence is handled by recurrence blob which is present in master item/1 item which is a serialized sting which contains things like start date, end date. And all the events can be expanded just by this recurrence blob. If now suppose one ocuurrence is deleted/modified that will have a separate calendar item, attached to master item. This is how it works in outlook today :)
would you like to elaborate? @CodeWithSahilBatra
Generating Event ID:
You were thinking right that no event, even in frontend, should be there without any id. Gaurav was also right in deciding that it'll be better if the id is generated from backend (incremental keys if SQL).
To, combine both - After user inputs the data for new event and clicks create button, we won't show the event created in frontend (maybe show an outline in dimmed color). We only show that created event normally when we get all the details back from the backend. Until then maybe run a loader, the turnaround time should be quick though.
Recurring Events:
Hmm this seems hard, :-p
I'll just keep one object for recurring events and calculate all events within a given period from that only when queried for. This way we can support never ending recurrences.
If any of the occurrence of a recurring event changes, we can create a different object altogether for that occurrence. But to keep it connected, it'll have recurrenceID as the eventID of the parent recurrence and normal random/incremental EventId as unique id. Maybe we could keep these in a separate table itself in db. For the parent event, maybe we could keep a flag like hasRecurrences set to true, so that while getting those, we'll calculate all events that need to be sent to backend.
We may need to keep another field like originalStartTime in occurance obj. so as to replace the original one calculated with this occurence when calculating all events from recurrence Event.
cancelling occurrence - create new event as mentioned and cancel that one
changing time/other details - create new event and change details in that
getting events - get all events. if any hasRecurrences then find those from recurrences table, replace with calculated instances and return the list.
Hopefully we can get everything done with this design, although it might need some case handlings.
For handling the recurring problem- when we set an event which is recurring keep all the ids of recurring event same as the first one. If user wants to update a particular event, keep a flag asking do you want to change this in all future events or only for this one- if flag get yes then no problem as it has same id it'll update for all else if only for that one then on updating should change the id of that particular event with a new id. By keeping the same id it'll also help in deleting all recurring events at once(we can use a flag on deletion also).
This is my first time watching any system design video and it was really fun watching. Now I'll deep dive into system design ❤
How about a recurrece id? Keep it same as the first event.
wasted 1 hour here, Interviewer asked me same system design but who will design data flow ?
exactly bro, they never seemed to agree on anything
Manager can maintain queue/priority queue and will have only one event which is about to occur,
when it's get removed from the queue, it notifies to user and adds next going to occur event back into queue. this way we can avoid maintaining all event duplicates.
This even helps in multiple notifications for the same events in case of all day event by pushing back same event into queue and even changing only one of the event occurence with some override flag.
I think a calendar event either can be a normal event or recurring event, we can store recurring event in some other data object or table with start and end data+time, this way once you try to find user events, you can check normal events and recurring event from different sources and plant the details to calendar accordingly. This way you will have more control over calendar events.
Great discussion. I would like to appreciate your efforts. I would love to have a follow up video on this, when we have a room for an event. And how double booking of room will be avoided, how concurrency will be handled in this system
I have received an offer from Walmart and gojek, Which is good to join in this current situation? Please suggest.
For recurrence, maybe one ID to identify the parent/series, and one sub ID to identify each individual instance of the recurring meeting.
That helps toggling if you're dealing with the whole series or just one instance
Gaurav is so much packed with the knowledge that his body falls behind when he's thanking through things.
I've to reach at this level.
Recurring event:
- Event class: Add recurringId
- Create recurring event: In EventService duplicate the event with same recurringId but different eventId, and store all events into a list
- Update recurring event: Add a flag 'isRecurring' for client to choose if all recurring events are to be updated as well. If isRecurring=false, the updated event is still part of recurrence.
- Delete recurring event: If flag isRecurrence=true all the events with same recurringId get deleted. Else, only a single event get deleted and is removed from the recurrence.
In this LLD i think the timezone is missing.User's from different location will not get specific event on time as per their Timezone
Didi, did you do pair programming to practice DSA or study alone?
Never thought I would binge watch system design videos😂 truly great content🔥
Great video Keerti.
Here's my approach.
EventDetails could be a child to Event and whenever you change a particular occurence of a recurring event, you create a new EventDetails object as a part of mutating an Event object.
If you want to update all future occurences, you create a new EventDetails object and bulk update all Events to have this new EventDetails child object instead of editing the original because that would mutate past events as well.
This also solves the "Event object without id" problem on the client side, you could send EventDetails object or a new object EventRequest.
Also, the events could be lazy-evaluated(created) by creating first N out of total E events, marking some Xth last event from the last Nth event(N-X) with a flag attribute, then use this attribute to trigger creation of the next N events on EVENT_END event(topic event, not Event) until all E events have been created, it would also work for never ending events. State for recurring events, requests rather, can be persisted using RecurringEventRequest object.
Did I miss something?
I probably did :P
We could have a UserManager which will have the user deets and the calendar object and the EventManager can then query the calendar object from the UserManager and then get the list of events, which will follow Single responsibility principle as well!
Thats a great session to learn from. Thank you for putting in effort to teach us.
Great work Keerti. Really appreciate the effort you are putting on both the channels. Managing work and youtube is itself a great feat and that too doing it regularly while maintaining quality is plainly superb. It's been 8 years in IT and watching your videos has motivated me to try learning about DSA. Have started my DSA journey by learning from your other channel.
Love the video, love the attitude shown especially by Keerti here! Although "shooting ideas" has it's own place sometimes when quick action is needed, but in most cases, an insightful approach and "stable" thinking is better suited to get to mature decisions.
Better not trip over and entangle ourselves into complexities. Many thanks for the video!
I have one question, why in whole video we tried to focus on creating object for response for example EventId (acting as both response for UI and domain for creating an event) and doing creation operation on that only. Why cant we have two objects like one will be domain and other will be response object out of it once core logic is written.
Actually, according to my understanding we should always have two POJOs for different purposes. LMK What you all think?
I love how a process that is intrinsically a hard slog is made so enthralling. I was literally on the edge of my seat following along the merging of minds in this colab. So glad I came across this vid. Something to sink my teeth into - "all animals have teeth - but do they all chew ?" I never knew design was such an engaging and entertaining process! Its left me chained to polling this channel
Def recurring.event(vid=True):
Yaaaaaay! Such a nice comment 🥺🥺🥺🥺
For recurring events we can make a single event and store the criteria for genrating future events
event maneger will tale care of generating the event for read apis etc
if a single event needs to be updated, we can make the actual event and store it actually in db otherwise for the rest we will relay on manager
(basically for the events in which user do any operation we will actually store the event in db otherwise it will just be computed with a cron logic)
Thanks for sharing Shivam.
What happens when event manager crashes?
I have been searching content for a lot of time on low level design. I just fall in love with your design patterns Playlist and enjoying this 😍 video with my coffee ☕️ and learning a lot.
Thank 😊 you Kirti mam !
I really learn fast when I see things in action rather than reading about them. This video really helped me understand how to approach the problem and how to keep the discussion with the interviewer.
Enjoyed the video. But you are using hashMap to store data in-memory which is the thing for LLD and then u suddenly talk about databases and indexing. Isn't it contracting?
May I know which tool you guys you have used in this video?
@KeertiPurswani We'll create a single Event, and when we have to update an event for a particular date (let's say 29/04/2023), we split event in three parts:
1. before 29/04/2023
2. for that date 29/04/2023
3. after 29/04/2023 (which details will be same as (before 29/04/2023).
Basically, update the recurring end date as 28/04/2023 in existing event and create 2 new events, one for 29/04/2023 and 2nd for upcoming dates (after 29/04/2023).
This way we can save lots of memory and also able to handle the case recurring end date 'NEVER'.
Great Video Mam,
I am learning Coding From Masai,
Hope You will help me in Future.
THank You!!!!!!!!!!!!!!!
Please provide time frame for the video would be more useful
I have a doubt, you mentioned we will store metadata or link metadata in treeset, if we will store metadata then we have to do update that's fine but how all will be pointing to the same metadata object? will we be having a different map which will store some id with metadata and we will then store that id in our treeset? Maybe I understood it wrong, please clarify what exactly is the meaning of that each entry will point to same metadata object?
maam there is no video on Aditya Verma Coding Interview and he is great coder so could try to make a video with him , He is just great and his way of explanation is just on another level .
so Plz plz make a interview video with him🥺
Good explanation.. I have one doubt here when u say having userid in a map, is it like when server starts reading all user details from db with event metadata and keeping it in memory?
thanks a lot .....Gaurav explained LLD very well
this is gold content.
wrt recurrence relations between events, how about we store only the first event that the user creates as a recurrence event, take in the rec_freq and num_of_rec_events; based on these facts we will create the future events(Note: we won't store them as seperate events, some client side processing is involved but thats okay). Also when the user wants to change an event which is a part of recurring event; if the user wants to change just this one event, then we just create a new event, otherwise if the user wants to update all the events following this event, then we only have to update the one event we has stored.
very informative, thank you
First comment on any video. But can't control.
@Keerti, i didn't get why said we should have ids generated on the frontend.
IMO, Ids generated on the frontend sounds like a bad idea to me. Less control on the client is much better.
When you call booKEvent api. You are making a POST request.
Backend should generate it and persist it.
For POST Request we use "Location" header.
In the response, client should get Location Header which has read url (GET request) of this event.
Why bother about id in the response. This location url might be (event/{id}) or anything.
Enjoyed the video and the discussions very well . It felt like I was brainstorming along with you two . You don't usually find quality LLD videos that much in the internet compared to DSA . Please bring more quality content like this
Its very rare to see Gaurav struggling this much 😄.
Hii mam I hope you are doing well . I have a question .can I join scaler academy after completing 12th . your answer is yes then tell me what is duration and course fee 🙏🙏🙏🙏🙏🙏
Thank you keerti and gaurav for a intriguing discussion. Really liked your energy in this.
where is the coding video ?
1.2.2 keeping guests optional or compulsory as a sub point
store the events for short time range like for 1 month or 6 months. Render the future events based on the cron expression only. If user changes the future events like updating description/titles then only create the respective which user has updated. Great content !!😄
Why do you zoom your faces? What does viewer get by seeing your faces. Keep your face videos smaller and enlarge the drawing
Love the thought process, simply amazing
Thank you! ❤️😇
Hello need a advice
Hello just need advice from you..
Hello ...i m 28 from commerce background
wanna do full stack devloper but like tech person theyvhave to start from ground i m from non tech i hv to start from underground level..can u suggest should i do basic fundamental of computer application networks basic database, excel ,adobe photoshop canva illustrator like basic of operating system what u suggest
or i should start from basic undertstanding of operating ssystem computer application computer network databasesp
before entrying in full stack developer course
Or should direct start from HTML CSS JAVA SCRIPT
Hii could you please tell me how can we apply in attlasian company
You can have single record for recurring event with a field 'except' where you store list of cancelled time
@Keerti Purswani
@Gaurav Sen , Please check RFC5545 recurrence rule standard to create recurring event
Calendaring in real system is totally different. They uses iCal format for storing events.
CRED asked me the same question in the last hiring held through codechef contest. Sadly I was unable to crack as it was literally hard that time :/..
Thanks a lot for these amazing video.
Liked now only, becuase i love your pairing. Thanks both
Thank you so much! Hope you love the video! ❤️😇
Can U Do A Video on the Maths we require to understand DSA
I rewind and see ,the way you say hai guys ,it's so cute 💖💖💖😂
Please record on a higher quality.
very useful content
Was watching this for how the conflict will be handled, but not covered in video :(
It's simple CRUD handled
@keerti I could also feel the conflicts in gaurav's mind, thinking too fast, happens with me also. Lastly I have gained a lot of respect for google/Teams calender and meeting feature.
I am from commerce background and i want to switch my career to data analytics where should i start my journey pleaseeee guideeeee meww
DIDI PLEASE HELP ME
I'm getting METALLURGY at MNIT JAIPUR and CSE at some other tier 3 colleges basically state government universities and in some iiit but are very costly.
Now I'm worried what to do as I want to work like you as a SDE. Please help me out.🙏
the guy looks unprepared, girl is so calm, probably frustrated too(with the guy)
WHy are you looking down in this video?
Great content but my thoughts.
Two experts took more than one hour barley covering the system.
Imagine handling this alone in under 45 minutes.
Take away: If you have not prepared well and practiced similar design in your past, then you are screwed :/
I can say only one word, you look awesome.
Too much discussion with recurring event
If you guys have that much good brain why don't you prepare for gate
🙏 ρ尺ｏΜ𝐎ᔕᗰ