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.
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.
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?
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
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
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...
Think you meant that transform is a compositor only property (it skips layout & painting) - you'd said paint. Small thing. Thanks for the fantastic content!
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?
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).
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?
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?
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.
![[Frontend System Design] - Deep dive into HTTP [Part 1]](http://i.ytimg.com/vi/gxF9fLo5XQw/mqdefault.jpg)
![[Frontend System Design] - Deep dive into HTTP [Part 1]](/img/tr.png)
![[Front-End System Design] - Typeahead component](http://i.ytimg.com/vi/9mjsRrJYOWE/mqdefault.jpg)
![[Front-End System Design] - Chat application](http://i.ytimg.com/vi/LEaiGjffLEs/mqdefault.jpg)
![[Front-End System Design] - Google Sheets](/img/n.gif)
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!!
You are killing it. Finally in the ocean of backend system design videos we have a river of Frontend system design :)
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.
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.
Hey Evandro, thanks for update! I might update existing video with your specific case. Will see :)
How about sending cron values to schedule a recurring call?
I feel I should pay for this. Awesome job! Thank you for sharing
literally the best youtube channel
wow! Great explanation on the IntervalTree
Thanks for the great video!
Having GraphQL and Event Driven architecture sounds like over engineering for such a simple app :-)
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?
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
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
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...
Yeah, but usually read operations greatly outnumber start / end date alteration operations.
It is a common way to optimize for data usage pattern.
Think you meant that transform is a compositor only property (it skips layout & painting) - you'd said paint. Small thing. Thanks for the fantastic content!
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?
I think the SSE used is to send notifications/reminders to users about upcoming events , createEvent wont be supported here I guess
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.
Thanks for the comment, yes, it's right! In the worst case, you may need to traverse the whole tree.
Hi, dude! It is really amazing content! Thanks a lot! I only started dive in system design, and your content is helpful a lot.
Nice video! Please keep making more :)
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).
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?
Very useful for starting). Thanks. Спасибо
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?
You have great content man!!!!!
nice to see you
Websockets are not compatible w/ HTTP/2? In what world ?
Thank you for this awesome video,
We want more video like this,
And also interview questions Answer video nedd
what are critcal resources in rendering performance ?
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.
Resources you need to render above the fold UI (JS & CSS).
I believe at the end you meant PWA (Progressive Web Apps) using ServiceWorkers to work in offline mode.
Nice
Amazing ! Would you mind share this draw picture to me? Wanna to review once have feel time. Thx so much.
I guess SSE means Server Sent Evens, not Server Side Events. Keep it mind :)
Sorry, what you call 'functional requirements' are actually 'non functional requirements' . ( e.g. accessibility )
GraphQL is not a good choice here for a simple application like Calendar graphql is over kill
Say CalEndar one more time
I double dare you
sure, CalEEEEndar :)
Actually, I've just realized that I'm pronouncing it wrong