Today I passed my first system design interview in a big serious company with zero previous experience in system design! I had 3 days to prepare and I mostly just watched your videos and googled stuff, thank you so much!!
I don't think that we need to take care of conflicting events in frontend side. Whenever we are going to create a new event, we will send all its participants including ourselves as a payload and that API will return all the events for individual participants for that duration. and using that information, we can decide if we need to change the time or not. Even if any participant is occupied, we still can create an event for him.
I have a feeling this is nearly impossible to cover all the things in one hour including time spent thinking specifically this is a quite hard question
It's another awesome video! Congrats and thanks dude! The only important feature that was not discussed in the video is how to implement the events that can be scheduled to be repeated over days, weeks, months, etc. In a past interview with Uber, I had exactly this problem and the interviewer focused mostly on this Google Calendar feature. It would be interesting to see a second part of this video covering this specific case.
Two imp questions: 1. how many total events will you have fetched in your UI/local store? events for 1 year? 2. How do you handle recurring events ? Same event is repeated infinitely at a given frequency (e.g. daily, weekly) I am assuming they are all treated as separate events by server, but there will be some dependency between those events? e.g. when we delete a recurring event, it asks for delete "This and following event".
Thanks for the questions. It's actually exact follow up questions a few friends got on the interview. 1. Locale storage has a 5mb limit. That is a plenty of data that can be stored. We can subscribe for events and receive them in chunks. The chunk size can be set based on the bandwidth and user device. Also don't forget that nothing keeps us from storing stuff in client cache 2. All repeated events treated as a separate entities with one exception, you also create another entity - special type of event RecurringEvent with the metadata about this event. All events that are instances of this recurring event will have a link to main event. On the backend, it will be easy to fetch all events based on main recurring entity. Also, you'll have to 2 options 1. Edit recurring event (will trigger update for all dependent events) 2. Edit current instance
thanks for sharing wonderful content. Question about the complexsity. I believe the worset case for these operations is O(n) because you could have a very skewed tree like a single line.
Isn't the Worst case Time complexity for the search here O(N)? I mean we could be looking at the entire tree in some cases, take your second example for reference. It was certainly not Log(N).
Great video. Question, you selected SSE protocol for this but that is unidirectional from sever to client only, the createEvent wont be supported there right?
Are all these things required for junior-level developers as well while interviewing ? Like the interval tree algorithms, server-side events, if not, then what should a junior developer focus on before going to a system design interview?
The interval tree strategy is only for events that spans multiple days right? For events that are within 1 day, for 1 hr or 2 hrs, a good strategy is to just have events for a day in a map or something and then apply an algo to see if the new Event's start and end time will conflict with any of the existing ones. Also, for multi day Interval tree strategy, imagine if an already created event is edited (start and/or end time), this will have to trigger recreation of the Interval tree as the interval tree is originally created using the Start date of the events, so that would get restructured OR if end date changes, the max date(s) for nodes in Interval tree may change...
Awesome video!! However I have a question here. If there is a event that spans across multiple days(3) how can we render it in a week view? in general how would one go about rendering week view here? Would he call fetch for each day and render? Also wouldn’t it be inefficient for first load to wait for year full of events to load?
this is awesome, if you are building on mobile iOS or Android and had to write data store to persistent, will you write your store as it is? or normalize more and write it?
IMO critical resources are resources ( files, scripts, etc..) needed for a web application to be up and running. For example, you may need to to load index.js to render the web page. On the another hand, analytic.js can be a not critical resource when we render the page. So we can defer analytic until later. It will bring in a lot of improvement in Largest Contentful Paint.
![[Front-End System Design] - Google Calendar](/img/logo.svg){kind=logo}
