Frotnend System Design: Design ChatGPT like a Senior Engineer

A few days ago, one of our menties got hired by a startup building an alternative version to chat GPT. So, today, together with Bogdan, we said, why not let's system design chat GPT's front-end and show you exactly how you can approach complex UI development like a senior dev. We're going to mention things like React fiber, Vlized list, rate limiting, web sockets and server sent events. Keep in mind, chat GPT had around 2 billion monthly users in April 2024 alone, which means that our system has to be highly scalable, probably one of the most scalable in the world.

Perfect, so I have a screenshot of GPT right here and if this is what you receive in the interview, it's very important that you follow a structure in order to design a good system and not go all over the place. As you mentioned, I also heard around this number, so 2 billion monthly visits in April 2024. So without any further ado, we're going to focus this system design exercise on the front-end.

The first thing you want to do before you jump into any solution is to really size the problem, to understand very well what's going on. And the number one thing you want to look at, it's number one, functional require. What do you mean with functional requirement? So, functional requirements are everything that the user will need in order to achieve the um their objective. So, basically, in the case of a UI, it'll be, you know, input fields, images, buttons, what do we need for them to be able to do what they are supposed to do?

So, you want to look at the user stories and like good interviewer, kind of write down, okay, what do we need as a user? So what do users need from a GPT like interface? Lucky enough, those chat interfaces are very simple. So usually, the user will type a query, right? And then they would receive a receive a streamed answer. And this is because this LLM, right? This uh large language models, they actually stream the answer, so we don't need to wait until the whole answer is generated, but they are streaming tokens to us.

So this is the main user story. answers is that they are quite they're a bit more complex than your traditional response, uh request response model that we have in HTTP. So I'm not going to detail too much on it right now, but for the very beginning, if you're not really familiar with this, you could even consider this would just be a request and then a response, right? For your brute force system design.

You just say, hey, you know what? We're going to launch a query, we get back a response. Now, just to give some insight on what we'll talk about later, the answer, you could actually open a socket or a communication with the back end and listen from the front end to events. And so the the back end will send you events that have a payload and have some data. And you basically can listen to those events and as soon as a new event comes in, you'll render your UI with a new chunk.

Right? So you open that channel, it stays in the background and you're listening to events. And as something happens, then we update state. We'll touch on that later. So this is one of the most complex part of this UI. But let's look at it, let's like, you know, let's make this as as a senior candidate. So there's a bit more, there's a couple more details. And so normally I would ask my interviewer, hey, is this in scope, like this model switch over here?

Do we need to cover this? And probably the answer would be no for the next, we're not going to cover how to switch models. Um, what about the shortcuts over here? Like this is something new GPT added and probably we will leave this out of scope too. Because again, it's not super interesting, it's not the core feature, so we're going to work on a simplified kind of version. Again, these interviews are usually 45 minutes.

So we're going to be really careful with the scope. So actually, the most important part of the interview is this. Right? This input field and then kind of render the answer, right? The the answer kind of comes here in the case of GPT. So basically, the user has to type a query and then it will receive a stream answer and then they get the query that so they can basically, you know, make more queries and they can view the conversation.

So they make more queries via the conversation and something very important. It's we probably also might want to look into the bouncing because it's an input field and we're sending that over. We will leave out of scope. Everything that has to do with file uploads. And I don't even know what design does. So, make sure with your interviewer you check those and tell me the scope. But usually they already kind of do it for you.

So, the first thing right now we have kind of the user stories. The first thing you want to do is to kind of come up with the UI that you need to satisfy those things. And in our case, we already have a screenshot, but I will draw it just next to our just over here. I'm going to draw a simplified version of this. And the reason for that is again, there's a lot of examples of system design. Few of them are oriented in, you know, on the front end.

If you do this, you are ahead of 95%. of the candidates, if rather than just going straight to the answer, you wireframe the UI and you try to extract the state. That's the core problem of most of those problems. or challenges and so the second thing I would do, it's to figure out. right, based on this functional requirements, I say 1.2 would be to wire. Now, do one your interviewer that you will go over non-functional requirements.

on a second stage so they understand that you are not missing. So this would be the non-functional requirements. Things like web performance, accessibility and uh I always misspell accessibility. And um security and even because it's GPT, I will add availability. Look, availability most of the times it's not super hard to achieve in the in the front end we'll see. Okay, so let's move on with the wireframe. Perfect.

So here we don't need to be a UX designer and I'm going to sketch the simplest version of it. Again, keep it simple, keep it small. We have a chat input field. Then we have a button. I'm going to do the same going out here, a button. Um usually this is an icon, but I'll just add a button and say chat. So it's more even simpler to model and as the chat answers. So this is usually fixed at the bottom.

state the distribution and then understand okay, why are we going to have state transitions? So, this is if you don't have a wireframe, then you can't really do a system design in the front end. Unless you start typing in the picture. But they might not give you this usually they give you an empty board and they just tell you design chart GPT. So, you would need to draw it. Um, part of being a front-end developer is knowing common UX patterns and being able to come up with a very simplified barebone UI without any prior design.

That shows seniority and it shows you can get stopped down even if you don't have a designer next to you. To, you know, feed you the the designs. So back to our wireframe, the next piece is basically the chunks of conversations that come through. As we start chatting with the model, um you probably get, you know, conversations over here. And then we send we end our messages, so we send a message over here.

Now, this is a rough and and the answer and then the same, right? So, they answer again and then we send another message. This will be a simplified version of the UI. Mhm kind of the typical chat interface, but chatting with an LLM that's behind some back end service that I guess we will talk about later. Exactly. And at 1.3, you want to talk about state management. Again, you have usually limited time and you want to make sure that you don't spend, you know, 30 minutes just wire framing it or just talking about requirements.

You need to be complete and concise, but also move the agenda forward. If not, the interview will will be over and you'll come across as someone that didn't do much. Um, so we have the wire frame and now it comes to state management. State management has two components, there's like the state and then the state transitions. So, it's like state variables and then state transitions. What are state transitions? Basically state changes from usually from two sources.

in the front end. Number one, source, user interaction, and number two, uh sync with the back end. So basically data fetching. We've seen a second. It's not really data fetching here, but that's how most of us are anyway. So let's see what are the state variables we got going to need here? Um, well, the easiest one, right? We have here a what do you call you can react a controlled import. That would be, let's call this query.

So that will be query and we can say the type of this would be a string. So the user types a query, that's our first state variable. To make it clear, this is a user query, not a database query. Yes, actually, that's a very good idea. We we just call this user search, user query. It's a text sentence. And whenever they're ready, they will click on chat. Um and so what happens when they click on chat?

What's the transition now? That depends on the uh back and API, right? Because we will make a request. Um so that would be our first state transition. Let me finish with our state variables. So we have our user query and then you see here we have I'll call this a conversation. So first state variable, user query and the second one, that would be a conversation object, let's call it this way. And here's where you need to be a bit even if you're a front end, you need to be able to model this into data structure.

So I will go really quickly on it, but if we were to store this, uh the first thing you see, it's a list of elements, but they are different. So sometimes we have the reply of the chat, then we have a user uh query and then we have another reply of the chat. So we could probably just render this by having a list of conversation items and it would have a different type. One of them would be a chat reply and the other one would be a user reply.

And depending on the on the different type, we might do render them differently. Um so this conversation object could be of type array, um an array of How would we call this? Like a reply, okay? And over here, I'll just use TypeScript to define what the data structure slash interface or type I reply would look like. So a good developer will always talk about data structures. Um so let's say the reply has obviously an ID, um probably it has a conversation ID.

We mentioned this is part of a higher order conversation. It probably has a timestamp and it's probably has um a type. Which we mentioned could be either like a user reply or a chat reply. be a string. This could be also a string or a date. And of course, a reply will have a content. Um, now this is the tricky part because you probably notice when you talk to GPT, it will render the response. So sometimes if you are asking it for a code, for code, it will give you some text paragraphs and just after that, it will give you some code snippet or a data a table of numbers and then go back to text. So that that will be when we need to do a bit more thinking. But for now, I have a feeling we could even work with text in the first um, in the first approach. One thing that I think is really interesting for the people watching is you started um diving in into the data types, right? Basically the traffic interfaces and you haven't opened your VS code yet, which also proves that programming it's as much of a thinking game. Then it's a it's more of a thinking game than a coding game. Now, I don't know how many um software engineers from the people watching us can actually do this, but you know, if they don't feel so comfortable typing typescript interfaces out of their head. What would you advise them? How could they model the data without? If they are not so comfortable with typescript? Well, if you don't want to add the types, you could do the same in plain JavaScript and ideally we can all um kind of just model this as an object. Maybe you are maybe this is an easier way to go, you say, hey, this will be a reply and this is the object. And then you can add this as a UUID, whatever, you know? So you don't really get into types. Uh the reason I get into types is because they tell you the structure of your components. You can model if you know the data structure, um it's just easier to model certain things, but you don't um, you know, even the timestamp. can be like, you know, 20 that 20 that 2024 and then the T for for timestamp and I think this is usually it has some UTC stamp um and then type could be a string. and the content could be some text. So just go for JavaScript. If you're not so comfortable with typescript. Doing it in typescript definitely will showcase a bit more seniority and confidence in your skills. So aim for that, but if you can't, downgrade it to like a JavaScript object. Awesome. Perfect. So if you have the data structure and the component like the state

variables. In the state transitions, you are 90% done with the UI. And this is a very clear way, they will probably understand this, we have a lot of candidates, they do this, and this is really usually the decisive factor in interviews. So, make sure you don't overlook this. And this is the foundation of everything else that will follow. And if you don't do this well, um, you're already starting on the wrong foot. So, just to recap. Functional requirements, user stories to then actual UI elements that we wireframe, and then deciding this state management, which has two dimensions, state variables, and state transitions. State transitions usually come from user interactions or synchronizing data with the backend. In 99% of the use cases in a web application. I'm so perfect. So now, what what is a state transition? Well, we do know that the users will click the chat button. And so let's imagine the simplest case. There's no conversation. They type a query. What do we do when they hit the chat button? And so, basically here you can write what is going to happen. We definitely will need to clear the input field. Um, that will mean setting the, um, what was the name here, the user query, equal to empty string. Right? That's our first state. Change. Uh, feel. And the second thing we need to do is we will make a back end, like a a request. So, let's call this is a call to the fetch API. Now, the big question is, what kind of request are we making? Is it a get, a post, a put? And in this case, we're actually creating one of those replies from the user. So, whenever in a rest API, whenever we create something, we probably will need will make a post. Right? So, I will go with post. You got to be careful because maybe a put will protect us against a different scenario. I'm not going to dive into it. But for now, let's imagine we make a post and this is why it's important. Even if you're going for a senior frontend goal, you need to know rest APIs. Okay. And and why is it a post and not a get? Um, so the reason for that is because in rest APIs, the http verb tells us what is the action. And get it's usually to read a resource, fetch a conversation, but we are going to create a reply. Because the user hit hit center. And that will be a create action. And usually we can create things with two kind of endpoints.

So we with two um HTTP verbs. Either a post or a Now, post will either update something if it's already there or it create it. So, we got to be careful. I think GPT the way it works right now, it's a post. Because if you type hello and then answer, and then you type hello again, it will actually answer like to your subs it will consider it like a new reply and give you a totally different answer. So, post is better because it'll create a new reply object all the time. Very important for specifically the front end engineers watching us. I know um rest APIs are something we usually consume. I know many of you are probably not so familiar with all the HTTP verbs, but in today's market, uh 2024, 2025 and beyond, you are required as a front end engineer to have a solid understanding of rest APIs, just like did. There is a reason behind that. Um I know many developers, I remember my front end days. I was paying too much attention to it because something back end people back end devs will take care of it. Um now that's those times are gone, you need to get your rest API knowledge. You need to update that. Cool, Bug. So, we take the input field, use a query, we make a call to fetch API. This is a post call. Um what's next? Perfect. So, we make a post to API/reply. And whenever we make a post, the response to that will be the created reply. And so what we should do in this state transition, it's push that to the reply answer. The reply um to the conversational array conf array that we are rendering. And basically at this point, we can actually re-render because um that's it. Like we sent. So, we're talking about the interaction on clicking the click, clear the input field. And then we push this thing to the server. Now, because we push that to the server, the LLM will think and then they will reply. And this is when the question of the streaming comes into place. Which is the key question of this style of interviews. So, how do we handle that? Especially at the level of these components. So, we can imagine this as a component, all this here. That can be a component that's rendering a conversation and listening for those updates.

So, there's two options to make this interactive. Um the simplest option where it's not streaming would be you just like whenever we um we create a reply, that the problem with connecting to software is how we listen to server updates. And the first way to do that would be, and this is the oldest one, it would be by polling. So, we call the server every, let's say, um one second. So, we basically call the um remember we mentioned we have a conversation object here, and we call the um the conversation to get the latest reply, and the reply should be the one from the LLM.

That would be the, you know, the the very old one. The problem here is that you're going to be bombarding your server from each client with calls every one second. That's what I wanted to say. I also remember we have about two billion users. So, you know, simple math, every second two billion calls, um Exactly. one way or another. Exactly. And I think it was uh two billion monthly visits, but the thing with GPT is that people make a lot of queries. So, the session is usually very long, there's a lot of queries, and so with the LLM and all that, the requirements on your backend will be just almost impossible to build, or way too expensive to be sustainable.

The second way, it's either using web sockets or using server send events. And basically web sockets are a a two-way channel that you open. So, we have the client, we have a client over here, and we open this two-way communication with the server. So, client and server, and they can both push events. So, the client can send things to the server, this direction, and the server can send things to the client.

And you have libraries for this, and you can listen to server, you know, updates as as a client, and then we render our re render this component. Like whenever we get a new event, that's basically um a new reply or a chunk of a reply, and we re render this displaying that. That's what that's how GPT looks like, but web sockets are quite complex, they have a lot of overhead, hardware overhead. So, scalability wise, Server sent events. Um how do server sent events works? This is a native API in the browser. It allows you to listen to an URL, and you can have the server publishing text chunks on that URL. So, it's not a two-way communication. So, remember this was basically two ways. Client Server and server to client. It's one way. So, basically the server can push little chunks of data, which look like fix chunks, you can think of um just little objects that you get every once in a while from the server. And this is how actually GPT chose the the team behind GPT chose to implement it. And you can find this out by going to your network tab when you're chatting with GPT, and you'll see there's an endpoint is calling and publishing the server sent events. So, um I actually did this by inspecting the network tab. Uh so, this is the approach I would go for if you're familiar with it. It's compatible with all browsers and it's way more scalable than web sockets for pooling. Um I mean, for someone building more traditional front and apps which don't need to be constantly listening to server updates uh web sockets and server sent events are quite new. But, I do feel and call me if I'm wrong, with the emergence of AI and chat applications, these kind of streaming architectures or um architectures where streaming is needed, it's becoming more and more common, right? So, it's something that if you're a more traditional front-end engineer, you should be looking in uh in 2024 and beyond. 100%. So, traditionally, you only needed to know web sockets if you're working in the on video games that you build in the browser or a chat, like a heavy chat interface, like a Facebook or one of those social networks. But, most of us didn't necessarily need to implement those. Um however, nowadays, you have more and more of these products, so it's very important for you as an engineer to add this to your tool belt, tool belts. The good news are this is a very simple API. You literally do something like new server sent on an URL, and then you can listen to events on that and whatever, you know, you have an on like when this even happened, then update my

that's pretty much it. It's not a complex API. Uh, it's very robust and it's not even in the browser, so no libraries, no need to learn anything fancy. Um, so let's go back to our picture with state transitions. Uh, user interaction, there was the clicking on the chat. So click click. The second one was type, so you remember we have the cursor and they type something. Um, apparently, I do not think we necessarily need um a state here.

I think the only state, when you're typing, the button maybe changes. So if if this is empty, the button is usually disabled. So that's something you can do based on the state, hey, if user query it's empty, then the state of the button is disabled. Uh, but you don't even this is um, this is what we call uh derived state. It's not even essential state, so we don't need an extra variable for its button disabled.

Uh you can derive that value from the user query being m. And finally, there's the last state transition, which is coming from the server cent event. So what will happen here is we will have something that looks like this, like it's like an on.data and we will provide a callback, right? So, there will be a callback, it will receive like some data from the server and on that we call our, you know, set state or whatever.

If you're doing react, it's state date, if you're doing something else, it's probably some other API and you know, push the data to our re. So, and that will trigger a reload. That would be our basically, so we have transition number one, state transition number two, and an optional one, number three. And that's the whole UI, we basically modeled basically literally the whole thing. And again, this will kind of serve the main purpose, of course there's more complexity coming in.

Right, if you want to synchronize different devices, if you want to have sessions, you get into storage and uh. Yeah, if you look at GPT, there is there's a bit more on top of that, like different formats of text. But I mean this would be enough for a proof of concept at least, right? Um, yes, again, this was constrained to the chat interface. What you do have and super interesting in GPT is this side tab where you have your different conversations.

So you have like a little title when you yeah, when you click on it, it will render that conversation. And that's when things can get more interesting because Imagine that conversation has, let's put it this way, imagine you have like 200 replies, right? And so all of a sudden the user clicks there and we need to regenerate this conversation and like re-render all those 260 replies. Um the number one thing you want to take a look at is the performance aspect. So again, when you talk to GPT, usually get this rich text, you get um you render the response not as a plain text, but you render code or you render tables, and that's expensive from a memory perspective. Even if frameworks like React are super efficient. So one of the best strategies is to um number one, you only want to render can you use uh virtualized list? Or you can use something like uh virtualized lists, which are basically based on the intersection observer, and they just render what it's in viewport. They render only the replies that are in the viewport. And the other thing you need to do is kind of a scroll restoration, scroll users down to bottom. When you use it, you use it the uh virtualized list only feature of React, is there some is there something similar in view and angular? So virtualized lists are a package for React that you can install and it will it contains a higher component and whatnot. I think there probably are some alternatives in view, for sure. And if not, you'll have to implement your own. Um, you could implement your own with intersection observer, which is a native browser API and do have some custom hooks that uh do that for you, but it's just a lot easier sometimes to use something that's built-in. Now we're getting into a new concept which is the intersection observer, right, which is pretty new in web development and was introduced for performance purposes mostly. Something you definitely want to look into if you're a senior mid-level even um front-end engineer interviewing right now. Yes, exactly. So you you touched something very important. Design native DOM APIs that you need to know as a senior front-end developer. Intersection observer and server sent events, okay? They are rather new, but they're very important. Um, now, if we have this memory feature

that's the most important thing. Virtualized list, and it's scrolling way faster at the bottom because the users users always want to be at the bottom. Also, when they start typing and they chat again, you want to scroll again. So, because you're playing with these scroll events, you might have to make sure you don't have any memory leaks. If you're using React, you need clean up functions in your effects. If you're attaching any of those, you know, on scroll listeners. That's something you want to mention during your interview.

I guess it's in these type of scenarios where you know, all this boring stuff about performance in the front end and why do we really need this? You know, React it's already fast, but when we're talking about global scale or even just regional scale, when you have these kind of events, that's where your knowledge is being tested. And this is why a senior frontend engineer these days is required to know so many things because UIs are getting more and more complex and user demands are getting more users are becoming more and more demanding, right? They want more from their apps, they want more scale.

Exactly, and with that in mind, let's move on to number two, which were the known functional requirements, and you want to you want pass any system design interview if you cannot go through them. Yourself have some sort of inner standards for how things should look like, like the interviewer shouldn't be asking you, oh, how would this look for a performance? I mean if they do, perfect, if they don't, you lead the interview, right? And you talk about web performance even if they didn't ask.

Of course, it's a conversation so you need some buying, but make sure you touch upon those. So, web performance uh like the other you mentioned, we will have around two billion monthly visits. Um from the static assets, like delivering the JavaScript and HTML, a CDN will probably do, and CDNs are super powerful these days and we can ship our JavaScript and render the UI and have it being, you know, super performant. Um again, it's a very simple UI, there's not so many components. Um and we also mentioned virtualized list as a way to keep the the UI fluid. The other thing is we are rendering and re-rendering a lot of components. If we wouldn't have frameworks like React, we might have to implement a priority queue

on how to render the replies, but React it's using React Fiber and internally priority Q with different priorities like 1 3 5. And all these renders uh things in order. So if the user is typing here, react will prioritize, you know, kind of reging the input field rather than this conversation. So it does that internally with React Fiber and we don't need to worry about it. And it's using the resources of the web browser very smartly uh by using the only request idle frame API.

So the more you know about it, the better. Uh but keep in mind a framework like React it's able to prioritize all these different renders to make the UI fluid. So I think um answering to this like reging the input field has priority of let's say zero and reging you know, whatever was fetched over the network has priority of two. And this keeps the browser switching between those things depending on when it's idle for the user, it looks like the UI is very fluid.

We have a specific video on React fiber on the channel, so make sure you check that one out and see how this works in there. Well that will solve our second problem, which is having a very fluid UI. The next thing would be accessibility, usually if we use semantic HTML, that accessibility comes out of the box. But I do know that GPT has certain shortcuts that you can use. I think uh cloud has it also like you press control C and then something happens.

So if you have this kind of things and you need kind of event listeners and maybe you need to work with a tab index. But for the most part, if you use um semantic HTML, then you'll be fine. Uh semantic HTML, it's all the HTML tags except for divs and spans, which have no semantic meaning. So here we would use a native input field, use a button here, and this could be rendered as P tags. Um, but again, if you have markdown or code, we'll see that would be a bit different.

And that's something I didn't touch on upon. How do we render markdown here or code, and what is the implication for, mentioned here, security? Now one of the biggest problems is you might have someone injecting malicious code maybe in your LLM and maybe it spits out some some malicious code and then it gets rendered here. And because of that, uh it's basically an cross-site scripting attack. where the user will render this code and maybe we we leak credentials or whatnot.

So one of the things you wanted to before you render this reply is to validate and sanitize this. Um and because you want to render code and uh text like reach text like, you know, bold, italic and whatnot. One of the best ways to do it is using something like React markdown, and there's probably a view markdown library. And they pretty much do all that for you. They validate the input that's actually markdown and then they render even code and you can have different styles if you want.

But I think you can solve that problem relatively easy by having a component and just putting the text we get from the LLM and have React markdown rendering that. You don't need to worry about how do I render markdown. You don't need to solve that problem. It's already solved. So we mentioned security, we mentioned excess attacks, of course, HTTPS and maybe OATH for the users. And then for the availability part, in the front end there's not so much needed.

Because again, for the most part, the front end is just fetching static assets. Um, it's not a good use case for server-side rendering. We do not have like critical SEO problems. Or first first input, like there's not so many images, you don't need the server to kind of render this on the server. It doesn't make a lot of sense. It's a very fluid interface. Um, so there will be a lot of changes on the client based of those components have state.

So, something like server-side rendering doesn't even make a lot of sense. Which means, and that's really good, because it means you can scale this application with a CDN for the most part. And CDNs are very cheap, very easy and very mature. Correctly, if I'm wrong, but I think a lot of the performance problem in the case of GPT is pressed to the backend, specifically to caching certain queries inside the LLM.

Right, and making the LLM not work so hard, right? But that's a that's more of a back end, right? If we get into the caching part, we go into the back end um part of side of things, which is not the scope of this interview. Exactly. And I think what they came up with in the LLMs, we can talk this about this maybe in a follow-up about the back end. Is that it's a semantic um semantic caching, I think they call it, or token-based caching.

Where they tokenize the query you're giving them and query and cash based on that. So basically they have the model tokenizing and interpreting your query and you cache the answer based on that. So you do a query based caching kind of. Um because all the answers are different, like all the queries can be different, but they're somehow alike. So, um, but again, as you mentioned, it's more of a back end topic. The only thing that's missing here would be how do we render, for example, this history very fast. So we might be able to cache this on the server on the client side by usually putting it in local storage. So you see all this this conversation history, it's quite heavy to be fetched all the time we render, especially when it gets big. Um and so the easiest way probably would be to put this in local storage and then bring it up when we render. Yeah, and that's pretty much it for state management, as you see, it's mostly component state for this view we've done need. We didn't even need like Redux context, uh like React context or any of those light tweak libraries um for these features. If you have a dark mode or if you have authentication, we will need it, but not for the feature we're discussing. Got it, maybe just to close up, if you can quickly walk us through the the high level process, because one thing that I realized it's you are. Number one, you have a process, I would say, and this is an advice for people watching us that might face such an interview. It's number one, if you look at not only the outcome, which can always vary, but the most important part in this in this kind of interviews is probably the process. And if you look at has a process, he had certain milestones he wanted to hit, then he is very methodic about the process. And even if the the the final goal is not very clear at the beginning, he just follows the process and he knows he will kind of get there. He also thinks on paper, in this case, using TL draw and is very transparent and uses that to kind of document his journey. He also thinks out loud in terms of he's walking us through what he's going to do and why, which answers a lot of questions on the interview part. Um and all these returns in the fact that he keeps his cool, stay on track and gets to the end, of course, by following process. Right, so if I were to ask you, what what advice or maybe yeah, maybe first.

tart with a high-level review kind of the at a high level what you've been doing. And if you can give us some hints for the people that are for engineers that are going to face a similar process, that would be amazing. Cool. So, always follow a process because it will give you a predictable result. Um and it will also allow the interviewer to follow you easily. If you don't use a process, we'll be going, you know, from state management to deployment and it's just going to go back and forth all the time.

Um the number one thing is you want to start with the functional requirement. And we start with the user stories and ideally from that, you already kind of can extract a wireframe version. Again, this is a front-end specific system design interview, it's a bit different from the traditional system design. That's why we need a wireframe. Now, once you have the wireframe, you can actually extract the state.

So that would be the next step. It's extracting the state management aspect. And you have state variables and we have state transition. Now, usually state variables and transitions have to do with fetching the data over API. So, that's a step I did not add it here, but you'll naturally fall into 1.4 kind of API definition. And this is what we did kind of API and data structure definition, which is what I did here and and here as a part of our post kind of discussion.

And finally, right, so that's that would be your first non-functional steps. So, functional requirements, wireframe with a component structure, state variables and transitions and finally, the API definition. And after that, you're already laid out and you can just go over these four non-functional type of requirements and discuss each one of them. So, web performance, accessibility, security and availability.

And so, as you saw, we talked about web performance and landed into virtualized lists and we talked about not having to use server-side rendering and using a CDN. Then we went to accessibility, which we just mentioned, so they know we know about it. But for the most part, using semantic HTML does the job if you cannot use semantic HTML because of any reason. And they ask you about this, then use area roles.

And finally, there's curity and availability, and usually security in the front end, it's all about either the SQL injections, which I did mention, and cross site script attacks, and then availability as the last one. So, if you cover even 80% of all this in a structured way, you will already stand out as a top candidate. And for the people watching us, if this seems like a lot, is because it is. We are talking senior front end engineer here, and that's why a senior, it's a senior.

But if you feel a bit lost or if you feel like there are certain concepts, you still need clarification on make sure you check out our dedicated playlist and you check the channel. Because Bgn and I are strategically picking up these different topics and making videos about them so you can be prepared. Also check the link in comments with a free tinkle assessment, this will allow you to understand what are your tinkle gaps respect to a senior full stack and front-end engineer and get a clear picture of what exactly, uh, you know, what kind of topics should you be focusing on for you to perform at the level that you've seen Bgn performing.

With that being said, Bgn, is there any last word, anything you like to add before we go? Um, as I mentioned, it's very important that not only we know the shiny things, but the fundamentals, and you've mentioned we've mentioned intersection observer and service and events. These are, you know, the boring DOM APIs that nobody looks at, but as you've seen, we're we're pretty much able to solve a very complex or problem with just using basic stuff, not not going fancy. So, do make sure that as a front end developer, you know the browser APIs and also make sure that you do know how to define a rest API, what to expect from a rest API and what to end. Awesome folks.

Bgn, thank you so much for your time and I guess we will see you all in the next one.